You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Server -> Client indicates that the requested operation execution has completed. If the server dispatched the Error message relative to the original Subscribe message, no Complete message will be emitted.
Client -> Server indicates that the client has stopped listening and wants to complete the subscription. No further events, relevant to the original subscription, should be sent through. Even if the client sent a Complete message for a single-result-operation before it resolved, the result should not be sent through once it does.
Note: The asynchronous nature of the full-duplex connection means that a client can send a Complete message to the server even when messages are in-flight to the client, or when the server has itself completed the operation (via a Error or Complete message). Both client and server must therefore be prepared to receive (and ignore) messages for operations that they consider already completed.
Completing the subscription from a client side is supported. When the Flux for the stream is cancelled, we send the "complete" message to the server. How to cancel the Flux depends on how you use it. Some operators like take and timeout send the cancel signal. If subscribing to the Flux with a Subscriber you can also get a reference to the Subscription and cancel through it.
We can improve the reference documentation on this topic around here.
rstoyanchev
changed the title
Support for sending "complete" message from client to server is not available.
Document how to cancel a subscription stream from the client side
Jun 28, 2023
Thanks you very much for your reply @rstoyanchev It makes sense. If you could improve the reference documentation, it would be great help for the users of this liberary.
https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#complete
Direction: bidirectional
Server -> Client indicates that the requested operation execution has completed. If the server dispatched the Error message relative to the original Subscribe message, no Complete message will be emitted.
Client -> Server indicates that the client has stopped listening and wants to complete the subscription. No further events, relevant to the original subscription, should be sent through. Even if the client sent a Complete message for a single-result-operation before it resolved, the result should not be sent through once it does.
Note: The asynchronous nature of the full-duplex connection means that a client can send a Complete message to the server even when messages are in-flight to the client, or when the server has itself completed the operation (via a Error or Complete message). Both client and server must therefore be prepared to receive (and ignore) messages for operations that they consider already completed.
The text was updated successfully, but these errors were encountered: