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 https://github.com/zulip/zulip/issues/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.
When we make a request and it fails because the server rejects the credentials, we currently treat that like any miscellaneous unexpected failure:
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 https://github.com/zulip/zulip/issues/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.