Retry long-poll failures, with backoff #184
Labels
a-api
Implementing specific parts of the Zulip server API
a-sync
Event queue; retry; local echo; races
beta feedback
Things beta users have specifically asked for
Milestone
A Zulip client long-polls an event queue on the server to get events. In the current prototype, if that request fails for any reason, the long-poll loop just aborts:
Instead, if the request fails with an error that we can expect to be transient, we should retry, with appropriate backoff.
split off as #514: [
We should also ensure that if the request doesn't come back within an appropriate timeout, then we treat it as having failed and retry. The Zulip server should always respond to a long-poll within at most about 60 seconds, with a heartbeat event if there's no information to convey. So if it's been much longer than that and we haven't gotten a response, then we should assume none is coming — the request or response must have been lost somewhere. (This part might get split out as a separate issue.)]For which types of errors we can expect to be transient and should therefore retry, see zulip-mobile at
tryFetch
:For how to control backoff, see zulip-mobile at
BackoffMachine
, background discussion at zulip/zulip-mobile#3841 (comment) , and the use ofBackoffMachine
intryFetch
. I think we can basically transcribeBackoffMachine
from JS to Dart and reuse that.The text was updated successfully, but these errors were encountered: