Retry and ungraceful server kill

[intellix]

Previously when using subscriptions-transport-ws if I was to kill/restart my server, it would eventually reconnect. Here I'm seeing that I need to manually implement retry logic and set the amount of times that I'd like to retry. So now I have something like this:

const ws = new WebSocketLink({
  url: `${apiEndpoint.replace('http', 'ws')}/graphql`,
  keepAlive: 30_000,
  retryAttempts: Infinity,
  retryWait: async function waitForServerHealthyBeforeRetry() {
    await new Promise((resolve) => setTimeout(resolve, 1000 + Math.random() * 3000));
  },
  on: {
    opened: (socket) => (activeSocket = socket),
    ping: (received) => {
      if (!received) {
        pingSentAt = Date.now();
        timedOut = setTimeout(() => {
          if (activeSocket.readyState === WebSocket.OPEN) {
            activeSocket.close(4408, 'Request Timeout');
          }
        }, 5_000);
      }
    },
    pong: (received) => {
      if (received) {
        latency = Date.now() - pingSentAt;
        console.log(`${latency}ms`);
        clearTimeout(timedOut);
      }
    },
  },
});

Now if I restart my server, I'm seeing that it only seems to retry 3x before completely stopping and it's as though the retryAttempts is ignored entirely. Is there something special I need to do for handling ungraceful server shutdowns with retrying? If a user is on site and the server goes down, I'd like the site to basically come back alive whilst he's looking at it and not know that he needs to refresh.

Screenshot showing that it only retries 3x:

[enisdenjo]

The default retryWait client option is using randomised exponential backoff, you should consider using the default instead. Custom retry strategy example from the readme is just in case you want to supply your own custom logic.

Can you expand more on the close event? Close code and reason would be helpful.

Furthermore, if the error is not a close event, it is probably a fatal error and they don't get retried by default. To control whether the error is fatal, you might consider using the isFatalConnectionProblem client option.

[intellix]

Sure, can use the default one but wasn't sure if it was included without it as I was having issues.

I'm basically killing my Node server with CTRL + C and then I see a bunch of these inside the client.subscribe error handler:

Actually.... I see that it only retries once and fails after the first error. The reason it tried 3x was because of this extra link I was using (which I removed now):

const retryLink = new RetryLink({
  delay: {
    initial: 300,
    max: Infinity,
    jitter: true,
  },
  attempts: {
    max: 3,
    retryIf: (error, _operation) => {
      const { operation } = getMainDefinition(_operation.query) as OperationDefinitionNode;
      return !!error && operation !== 'mutation';
    },
  },
});

The error:

Unhandled GraphQL subscription error Event {isTrusted: true, type: 'error', target: WebSocket, currentTarget: WebSocket, eventPhase: 2, …}

[enisdenjo]

I still don't see the close code and reason (err.code and err.reason). If there is none, it is probably a fatal error and they don't get retried by default.

To control whether the error is fatal, you might consider using the isFatalConnectionProblem client option.

[intellix]

it works with that actually:

isFatalConnectionProblem: () => false,

Thanks so much, I wouldn't have had a clue :)