On Normal Closure the app doesn't retry even when shouldRetry set to true

[OttlikG]

Screenshot

Expected Behaviour
I'm expecting the connection return to normal after the server drops cause of restart.

Actual Behaviour
I set the following options:

{
  shouldRetry: () => true,
  retryAttempts: 50,
}

to createClient but the retry mechanism doesn't kicks in.
As I see the process doesn't get to shouldRetryConnectOrThrow so the shouldRetry configuration doesn't get called.

Debug Information
I run Hasura graphql server which throws the following error on Kubernetes pod restart.

[
    {
        "extensions": {
            "path": "$",
            "code": "postgres-error"
        },
        "message": "connection error"
    }
]

The socket.onclose function gets called when server restarts without the retry functionality.
The event type is Normal Closure.

If any more information is needed, let me know.

[enisdenjo]

Hey there, close code 1000: Normal Closure means we're good and done - it should not be used as a problematic close code. graphql-ws intentionally skips this code and will not retry it:

graphql-ws/src/client.ts

Lines 841 to 844 in eea18ce

	// normal closure (possibly all subscriptions have completed)
	// if no locks were acquired in the meantime, shouldnt try again
	if (isLikeCloseEvent(errOrCloseEvent) && errOrCloseEvent.code === 1000)
	return locks > 0;

Consider using 1001: Going Away, or even 1012: Service Restart, or 1013: Try Again Later, as a better-fitting indicator that the server is being restarted.

[OttlikG]

Not sure if there is anything I can change. I think it's Hasura that close the connection with 1000 on server restart.
Will try to run by this issue at their Github and come back later.

[OttlikG]

As it turned out, preparing the backend to send the aforementioned codes as a response would be complicated. We're facing this issue when Kubernetes do a rolling deployment, and it's difficult to signal when it's not a Normal Closure. In the interim, we would like to patch this library in a way when we receive the 1000 code; it should be interpreted as a retry.
Do you have any suggestions on how to do that?

[enisdenjo]

You can look at this part:

graphql-ws/src/client.ts

Lines 841 to 844 in eea18ce

	// normal closure (possibly all subscriptions have completed)
	// if no locks were acquired in the meantime, shouldnt try again
	if (isLikeCloseEvent(errOrCloseEvent) && errOrCloseEvent.code === 1000)
	return locks > 0;

.

An alternative would be a custom WebSocket implementation that augments the close codes so that it converts 1000 to any other erroneous close code.

[KayakinKoder]

Sorry for asking @enisdenjo before trying this out myself, but we're using Hasura also and I was wondering if EventClosedListener or something else could be used to potentially detect this situation on the client? Thanks

[enisdenjo]

Not really, when the closed event is emitted - its already too late - the connection is closed. You can do what mentioned here, provide a custom WebSocket implementation that changes the 1000 close code to something different.