Skip to content

Reset backoff interval after successful connection #554

@gnprice

Description

@gnprice

Since #184, we retry long-poll failures, with exponential backoff up to an interval of 10 seconds.

Even after the device is again able to reach the server, though, the backoff interval on next failure remains 10 seconds, for as long as the app keeps running. That seems unhelpful. Instead, when we find we can again consistently reach the server, the backoff intervals should reset to what they would be if the app were restarted.

The simplest thing to do here would be: as soon as there's one more success, just reset the backoff to its initial state. I'm not sure if a more complex strategy would be best in general. But I think for these long-poll requests the simple thing is fine, for the reasons below.

Detailed reasoning

The possible risk in completely resetting backoff on a single success is that if the server is having trouble and handling some but not all its requests, that plan would mean we'd do a lot more retries, partway toward what would happen if we weren't backing off at all. I'm not sure if there's a standard recommendation for how to strike a balance there.

However, these particular requests are a long-poll — which means that a successful request most often takes a long time to come back: up to 60 seconds. Probably most of the time it's longer than our max backoff interval of 10 seconds. So if after that, our next request randomly fails (because the server is having trouble) and we retry in 100ms, that's not that different from if we retry after 10 seconds.

Metadata

Metadata

Assignees

No one assigned

    Labels

    a-apiImplementing specific parts of the Zulip server APIa-syncEvent queue; retry; local echo; races

    Type

    No type

    Projects

    Status

    Done

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions