How to ensure that no subscription response goes undelivered ?

[97amarnathk]

Use case

I have a graphql-ws implementation set with retry attempts incase of network issues, or authToken expiry, built using this example https://github.com/enisdenjo/graphql-ws#auth-token

Because of the following issues, it can happen that a client doesnt receive the message even though the server has published it :

1. Server publishes a message M, but just before onNext, websocket closes due to a network issue, client retries and takes 5 seconds to reconnect. All messages published in these 5 seconds will go undelivered, as well as the message M
2. onNext has an authToken check. So now server publishes message to client, but onNext sees that the authToken is expired, it closes the socket, client retries connecting. Again some messages will be dropped.

For a critical use case like a chat app or a data sync, this will lead to some inconsistencies.

TL;DR -> All payloads passing graphqls execute callback, should be delivered to all clients which are connected at that moment.

How can this problem be addressed ?

[enisdenjo]

Hey hey, lets jump straight to it. graphql-ws is designed to not swallow anything, it will fail if you try sending a message over a closed socket. Therefore, you will be fully aware of any untimely sends and are free to implement your own WS server that is more robust in this area through makeServer.

Check the "Server usage with ws" recipe which showcases a commented, super simple, integration of ws with graphql-ws.

• One way would be to simply listen for a socket close and let your system know it is trying to send over a gone client. You're free to alter your system's behaviour with this flag however you want.
• Another way would be to catch sends on a closed socket using the cb argument in onMessage. The cb argument is a Promise and will resolve only when the requested operation completes. Everything that could possible go wrong during the execution (of queries, mutations, subscriptions or even connection initialisation) will result in the cb being rejected. So, you can surround it with a try/catch block and act accordingly.

Implementing a "missed" queue to either case from above is possible. For example:

1. You record the subscription ID on which the server is trying to publish over an already closed socket
2. Queue up the messages
3. Wait for the client to resubscribe with that ID
4. Finally, drain the queue

This will work because the client will always resubscribe with the same ID of the subscription that was abruptly terminated.

However, be very careful of how you identify your clients! You dont want to drain the queue to a potential attacker that impersonates the original client by using the same subscription IDs. Nevertheless, with good security practises on the connecting phase, you can be quite safe with the queue draining through the right sink simply because graphql-ws uses UUIDs as subscription IDs and ID collisions are unlikely to happen.

[97amarnathk]

Oh.
also hydrating will be for each subscription for each client, whereas draining the queue will be once per client.

[enisdenjo]

Yap, you can also decide to hydrate only if the socket closed abruptly (following same principles from above).

[97amarnathk]

Is there any reference implementation done by anyone for graphql-ws + server side queueing on distributed servers? The issue in my case is that its not guaranteed that after reconnect the websocket will connect with the same server instance.

[enisdenjo]

Sorry, not any that I am aware of.

[theogravity]

How are you tying the subscription message UUID to the backing pubsub store in question? Wouldn't it be that you would use an offset / id provided by the backing store and not the generated UUID from graphql-ws?