Handle unrecoverable long-poll failures

[gnprice]

As described in #184, when a long-poll for events fails, the current prototype just stops polling. That issue is about transient failures, and #185 is about a non-transient but recoverable error. That leaves failures that we can't expect to fix, neither by just retrying nor by some other request: e.g., the user's auth credentials were rejected.

At a minimum, in this case we should give the user some indication that the data they're seeing is no longer being updated: e.g. set the isStale flag mentioned in #185.

If specifically what happened is that authentication failed, then we should probably ask the user to log in again to that account.

If we do those two things, and also make sure the user always has the option to navigate away so they can add or choose another account to use, then I think that's pretty satisfactory. This situation shouldn't be common, so it's OK if it isn't super smooth as long as there's some reasonable way for the user to recover.

[gnprice]

Now that the following two issues are complete:

• Show "Connecting…" banner (or equivalent) when server data is stale #465
• Show detailed poll-failure feedback, in beta #555

the current behavior is:

At a minimum, in this case we should give the user some indication that the data they're seeing is no longer being updated

This is done (as #465).

If specifically what happened is that authentication failed, then we should probably ask the user to log in again to that account.

The user will get a "snack bar"-style popup saying generically "Error connecting to Zulip. Retrying…". That has a "Details" button; if they hit that, they get a modal saying something like:

Error

Error connecting to Zulip at https://chat.zulip.org. Will retry:

ZulipApiException: 401 UNAUTHORIZED getEvents: Invalid API key

(The exact message at the end, from "Invalid" on, might vary depending on the nature of the auth failure.)

So with that, it's not as clear or convenient as it could be, but the information is there. And the user can indeed always navigate away so they can add or choose another account. Moreover after we have #463 (coming soon), the user can forget the account that had the problem, in order to add it anew.

---

In short I think this issue is done according to its title: we do handle these failures. I'll file a fresh issue for the remaining task of noticing auth failures specifically and flagging those for the user.

[gnprice]

I'll file a fresh issue for the remaining task of noticing auth failures specifically and flagging those for the user.

Done:

• Handle auth failures on registerQueue and other requests #1054

While writing it up I realized that registerQueue is actually the more important case than getEvents (i.e. long-poll), for reasons explained there.