Commit Graph

5 Commits

Author SHA1 Message Date
Robbie McKinstry d2d73a6e58
Eliminate async promise executor.
Promise executors are not intended to be async. This PR enforces that.
2023-05-11 13:05:43 -04:00
Robbie McKinstry e05a3bd81c
Apply autoformat
This commit applies the Rome autoformatter to the Node SDK.
These changes are automatically produced. To reproduce these
changes, run `make format` from inside sdk/nodejs.
2023-04-28 18:27:10 -04:00
Justin Van Patten 1fca4e9d89 [sdk/nodejs] Cleanup use of `asyncTest` and `assertAsyncThrows`
The `asyncTest` and `assertAsyncThrows` helpers were necessary when originally written, but are no longer needed as Mocha has built-in support for testing async functions that return promises, and Node's `assert.rejects` can be used to assert whether a promise has been rejected.
2022-11-09 15:08:08 -08:00
Komal 6949101428
Replace equal and deepEqual with strictEqual and deepStrictEqual () 2020-10-21 10:21:47 -07:00
Alex Clemmer a40008db41 `StreamInvoke` should return `AsyncIterable` that completes
A user who calls `StreamInvoke` probably expects the `AsyncIterable`
that is returned to gracefully terminate. This is currently not the
case.

Where does something like this go wrong? A better question might be
where any of this went right, because several days later, after
wandering into civilization from the great Wilderness of Bugs, I must
confess that I've forgotten if any of it had.

`AsyncIterable` is a pull-based API. `for await (...)` will continuously
call `next` ("pull") on the underlying `AsyncIterator` until the
iterable is exhausted. But, gRPC's streaming-return API is _push_ based.
That is to say, when a streaming RPC is called, data is provided by
callback on the stream object, like:

    call.on("data", (thing: any) => {... do thing ...});

Our goal in `StreamInvoke` is to convert the push-based gRPC routines
into the pull-based `AsyncIterable` retrun type. You may remember your
CS theory this is one of those annoying "fundamental mismatches" in
abstraction. So we're off to a good start.

Until this point, we've depended on a library,
`callback-to-async-iterator` to handle the details of being this bridge.
Our trusting nature and innocent charm has mislead us. This library is
not worthy of our trust. Instead of doing what we'd like it to do, it
returns (in our case) an `AsyncIterable` that will never complete.
Yes,, this `AsyncIterable` will patiently wait for eternity, which
honestly is kind of poetic when you sit down in a nice bath and think
about that fun time you considered eating your computer instead of
finishing this idiotic bug.

Indeed, this is the sort of bug that you wonder where it even comes
from. Our query libraries? Why aren't these `finally` blocks executing?
Is our language host terminating early? Is gRPC angry at me, and just
passive-aggrssively not servicing some of my requests? Oh god I've been
up for 48 hours, why is that wallpaper starting to move? And by the way,
a fun interlude to take in an otherwise very productive week is to try
to understand the gRPC streaming node client, which is code-gen'd, but
which also takes the liberty of generating itself at runtime, so that
gRPC is code-gen'ing a code-gen routine, which makes the whole thing
un-introspectable, un-debuggable, and un-knowable. That's fine, I didn't
need to understand any of this anyway, thanks friends.

But we've come out the other side knowing that the weak link in this
very sorry chain of incredibly weak links, is this dependency.

This commit removes this dependency for a better monster: the one we
know.

It is at this time that I'd like to announce that I am quitting my job
at Pulumi. I thank you all for the good times, but mostly, for taking
this code over for me.
2019-11-12 13:51:19 -08:00