Bypass fatal error code no retry logic

[ccurtis826]

Hello!

I'm reaching out from Atlassian and we've been encountering some scenarios where the library's non-retry behavior for the fatal error codes limits the client's ability to implement retry logic.

After some discussion, we've been thinking that having a configuration option in createClient to bypass the fatal error code behavior would be beneficial. This would allow clients more customization to attempt to recover at a later time, for example by implementing backoff strategies, rather than having the library enforce a hard stop.

We'd be curious to hear your thoughts on adding a configuration option that allows clients to override or bypass the default fatal error handling?

If you're open to this, we'd be happy to discuss further or even contribute a PR.

Thanks for your consideration!

[enisdenjo]

Hey! Interesting, I was under the assumption that I got the codes covered correcly. May I know which code do you want to retry but the client deems it non-retryable?

[ccurtis826]

Yeah for sure, in particular we were using the 4429 code to close the socket when the websocket server would enforce rate limiting on connects.

[enisdenjo]

Hmm, why 4429 though? That is an graphql-ws internal subprotocol error where a client tried to send multiple "connection init" messages, it's not really for rate-limiting.

Since you have control over the close codes (you're using a WS user-land code), why not just use another code? You can create your own code specific to the case and even handle it better on the client side (like respect the timeout).