Retrying with exponential back-off and randomisation

[enisdenjo]

Story

As a client

I want to use exp back-off and randomisation on retries

So that I prevent the "thundering herd" problem and avoid DDOSing the server when it restarts

Acceptance criteria

• Client uses the exp back-off for retries
• Client randomises the initial timeout on retries

[Shahor]

Hey @enisdenjo 👋

Great on work on the graphql-ws library!

I'm fighting a bit with this issue this morning, I'm seeing a double problem here:

• When my server restarts, the client waits retryTimeout before making a new connection, but if the server is not started yet when the retryTimeout is done, it'll just loop retryAttempts times without respecting the retryTimeout. What can I do to make sure retryTimeout (or retryStrategy(tryNumber: number)) is properly awaited?

The scenario down below is happening with the following configuration:

return new SubscriptionLink({
      url: subscriptionsEndpoint,
      retryTimeout: 30e3,
      on: { /* event handlers */ }
})

As you can see, the retryTimeout is not used for the socket reconnection attempts.

• I've see the pr feat(client): Retry with randomised exponential backoff or provide your own strategy #84 , I think it would be nice to actually give access to the retryStrategy ala ioredis so everyone can implement their own backoff strategy according to their needs, wdyt?

[enisdenjo]

Hi @Shahor, thanks for reporting this - it is most probably a bug! I have a hunch about what causes it, will fix it probably together with the upcoming PR.

Regarding the retryStrategy in #84 - I like the idea a lot! Will include this in the PR, thanks for the suggestion. 👍

[Shahor]

Ah, that is great news thanks for considering it 🙇

I'd be happy to test this in my environment if you want once ready.

[Shahor]

@enisdenjo I am very sorry for being pushy with this, is there any chance you'd have an ETA for at least the buggy part?

I'm happy to help if needed to make this move forward :) (It's blocking us a bit as we're switching to graphql-ws because of a bug that it fixes compared to subscriptions-transport-ws)

Just let me know if I can help you on this :)

[enisdenjo]

No worries, I can understand!

I'll try pushing the fix later today (am currently swamped with my day job, as soon as I am done - I'll come back to the PR).

[enisdenjo]

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[Shahor]

@enisdenjo You rock 💪