OnUnsubscribe?

[JakeCooper]

Story

As a enjoyer of this library

I want my server, ideally my async generator, to be notified when the cleanup function, returned from client.subscribe, is called

So that I can close downstream connections to other services (in this case a GRPC stream)

Acceptance criteria

P0: server is notified on unsubscribe
P1: handler is notified of unsubscribe

[enisdenjo]

As per the Observable pattern, a stream is stopped with either an "error" or a "complete" event. If you dispose of the client.subscribe subscription, or if the subscription is completed by the server, or the query/mutation is done - the complete callback in the subscribed sink will be called.

On the server side, what you're looking for is therefore the onComplete server hook. It is called for each query/mutation/subscription after it has completed for whatever reason (user disconnected, server completed, client completed/unsubscribed). An same on the error side with the onError hook.

Additionally, if you're looking for hooks for when the client completely disconnects/closes the WebSocket connection, you might want to check onDisconnect and onClose respectively.

[gschier]

I assume that, if my iterator never yields, it just gets stuck here on line 797?

[enisdenjo]

Exactly. Your iterator must yield and finally return/complete, for the subscription to behave as you expect and as it should.

So, I guess my question is... if we have our GRPC stream listener inside our generator that never (or in a long time) returns, how can we detect that the WS client has stopped listening from within the generator in order to shut down the GRPC stream and exit the loop? It seems as though we can only exit after another response from the stream has arrived and we finished the next iteration.

When the WS client stops listening, the subscription iterator will have its return method called:

  // ...
  subscribe: async (root, { deploymentId }, ctx, info) => {
    //     👇 this one
    return (async function* () {
    // ...

It is your task to provide an appropriate return method for the subscription and propagate the invocation to your iterators, in this case to streamDeployLogs.

I'd recommend looking over the "client usage with AsyncIterator" recipe once more in-depth for how to do that properly.

[enisdenjo]

Also keep in mind that this is not only about graphql-ws and the subscriptions working properly - if you don't dispose of the stream from streamDeployLogs properly, you're facing a memory leak.

[gschier]

I'd recommend looking over the "client usage with AsyncIterator" recipe once more in-depth for how to do that properly.

Ah, yes that looks like it should work! I could only find the next() method documented for Async Iterators but just discovered that throw() and return() are part of the Generator spec instead. Thanks for pointing this out 👍🏻

Also keep in mind that this is not only about graphql-ws and the subscriptions working properly - if you don't dispose of the stream from streamDeployLogs properly, you're facing a memory leak.

Yep! We'll be sure to do this, and thanks again for being such a huge help! 🥳

[enisdenjo]

I could only find the next() method documented for Async Iterators but just discovered that throw() and return() are part of the Generator spec instead.

Yes, you're right. Iterators are objects which allow traversal over a (often) finite set of values that have an end; while generators, on the other hand, are actually functions that "generate" the next value on-demand. They are also iterators, but what makes them special is that they run only when next is invoked.

Because of these intrinsic differences - generators must implement the throw and return methods as means of communicating an end, while pure iterators don't have to.

[enisdenjo]

Moved to #283 (reply in thread).