Is there a way to control the websocket reconnect backoff?
Basically I want to cap the reconnect time to 10seconds. I was just doing some local testing and very quickly went over 20 seconds:
Any help greatly appreciated.
11 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
Not a direct answer to your question, but would an API like
attemptReconnectImmediately() potentially suit your use case?
Since there's a lot of reasons the connection could be failing (ranging from flakey internet to Convex being down), it's generally nice to have some generous exponential backoff. But your end users probably want to know when they're disconnected and be able to reconnect instead of being stuck waiting for a reconnect.
(I'm kind of guessing at what you might want to do here, so let me know if I'm totally wrong -- would love to understand more about the behavior you want here)Thanks for taking the time to reply @sshader
It’s really just like I said - the behaviour I want is just to reduce the max time between reconnects - 10 seconds would be ok, it doesn’t need to be zero. I’ve basically got some data that is being pushed from one device to another and want to keep them as close as possible.
I’m assuming
attemptReconnectImmediately() is something I’d call anytime I want to reconnect (as opposed to calling it once to setup a config option - which I don’t think would make sense).
The problem is that I always want the devices to be as close to in sync as possible. So the proposed API would lead to me setting up some sort of listener which always calls attemptReconnectImmediately() on any disconnect. Which basically removes any exponential backoff unless the client is expected to re-add it.
The suggested API is also more work for the user than specifying some different config parameters.
The other observation I have with the exponential backoff is that it went to 20 seconds + within a few seconds. So if I hit a patchy bit of internet and am suddenly waiting 20 seconds to reconnect. Note that the app I’m developing will be often used on mobile devices.
The two options I can see are:
1. Let me manually specify the max time between reconnects (with some lower limit presumably).
2. Increase the time it takes to get to the larger reconnect times so that patchy internet isn’t penalised too hard.a couple of notes -- these may be obvious, but leaving them here for completeness
1. in general, it's in the interest of convex to have clients back off a bit. if we're down due to load, having reconnection hammers isn't ideal
2. you'll see the times bounce around. this is because convex jitters the backoff times so that we don't cause any kind of harmonics that cause all clients to hit us in the same second
so, the backoff routine in convex is capped exponential backoff with jitter
GitHub
convex-js/src/browser/sync/web_socket_manager.ts at 76dfc0cbdf703ce...
TypeScript/JavaScript client library for Convex. Contribute to get-convex/convex-js development by creating an account on GitHub.
the max backoff centerpoint is 16s
so given jitter, this means a reconnection may be attempted anywhere between 8s and 24s later
this helps evenly distribute reconnections onto our traffic layer
Yeah, I understand. So a reduction in the max is unacceptable, what about making it take longer to get to the max?
Another thought:
If the client has no internet then short reconnect times are presumably fine since it's not impacting Convex's infrastructure. So what about using something like the navigator.onLine property to help determine the shape of the exponential backoff?
absolutely, a goal of the API sshader suggests above would be that you can use naviagator.onLine, tab visible, or whatever other signals you have to do it sooner. Or retry another API with no backoff then retry the websocket once that succeeds
re incorporating that into the client, maybe, but we'd like to try it with a recipe first and hear how it goes before baking it in for everybody
That sounds good, but what I was trying to get at is that the problem with exposing something like
attemptReconnectImmediately() to users is that it can be overused. Which would stop reconnections being nicely distributed and have an impact on the Convex infrastructure.
I would be happy to have it (especially if it comes with a callback to tell me when the websocket is down).... I just don't think you should trust us users 😄Yeah it would probably have a backoff too if you keep calling it
Yeah, that would probably work... Although it makes me want to ask for an escape hatch for that as well, maybe
attemptReconnectImmediately_immediately() 😄