Skip to content

Handle auth failures on registerQueue and other requests #1054

@gnprice

Description

@gnprice

When we make a request and it fails because the server rejects the credentials, we currently treat that like any miscellaneous unexpected failure:

  • For registerQueue, we retry (with backoff).
  • For getEvents, we notify the user and retry (with backoff).
  • For most requests (which correspond to the user directly taking some action in the UI), we ignore the failure. The user can always try the action again if they choose.

But it's normal and expected that sometimes the credentials will be rejected — for example it happens if the user resets their API key. (Ideally that in turn would happen on changing their password; that's zulip/zulip#21636 .) We should notice this has happened and do something to help the user get reasonably smoothly to logging in again.

The most important case is for registerQueue, because that's the first request we make (to a previously-logged-in account) when the app starts up, and therefore by far the most likely request to be the first one we make after something makes the old credentials invalid. The next most important is getEvents, because that will typically be the first request we make after opening the app if it was in the background.

Once we have #463 (coming soon), the user will always be able to forget the existing logged-in account in order to try logging in again. Because this is an uncommon situation, I think that's good enough for launch. So milestoning this as post-launch.

Metadata

Metadata

Assignees

No one assigned

    Labels

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

    Type

    No type

    Projects

    Status

    No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions