Time out initial fetch and go to account-picker screen. #4754

We'll use this in `tryFetch`, in an upcoming commit, so that we can interrupt in-progress attempts to contact a server when they take too long. See discussion [1]. [1]: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Stuck.20on.20loading.20screen/near/907693

To be dispatched when we want to give up on the initial fetch. It navigates to the 'accounts' screen so a user can try a different account and server. Logging out wouldn't be good; the credentials may be perfectly fine, and we'd like to keep them around to try again later. It sets `needsInitialFetch` to `false` [1], just like `INITIAL_FETCH_COMPLETE`, while retaining a different meaning than that action (i.e., that the fetch was aborted instead of completed). Setting `needsInitialFetch` to false is necessary to ensure that a subsequent initial fetch can be triggered when we want it to be. As also noted in 7caa4d0, `needsInitialFetch` is "edge-triggered". (That edge-triggering logic seems complex and fragile, and it would be nice to fix that.) See also discussion at https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Stuck.20on.20loading.20screen/near/907591.

…ch`. The TODO doesn't specifically mention that we want to retry on network-failure errors, but we do, so add that too. If we get some strange, totally unexpected error caused by a bug somewhere, we shouldn't continue the retry loop. Not only would that waste the user's time, but it means the error basically gets swallowed, and it makes it much harder for us to detect it and debug effectively. So, fail early on exceptions like that. See our doc on exception handling: https://github.com/zulip/zulip-mobile/blob/master/docs/style.md#catch-at-ui.

So far, `tryFetch`'s only callers are in the initial fetch; so, add handling for the `TimeoutError` there. The choice of value for `requestLongTimeoutMs` comes from a suggestion in zulip#4165's description: > As a minimal version, if the initial fetch takes a completely > unreasonable amount of time (maybe one minute), we should give up > and take you to the account-picker screen so you can try a > different account and server. Fixes: zulip#4165

As Greg points out [1]: > Basically it's an internal error in the app. But the user is > probably better off getting kicked back to the account picker than > having the loading screen continue indefinitely -- it means at > least they can try again and see if the issue recurs, or try > another account and see if they can at least use that. [1] zulip#4754 (comment)

As Greg points out [1], this makes the most sense conceptually; it's happening at the bottom of the loop, just before a new iteration starts. The `return` in the `try` block is enough to ensure that this wait won't interfere with a successful fetch. [1]: zulip#4166 (comment)

Greg points out that we don't always want to retry the initial fetch on server errors [1]: > Ah, I think in #M4165 the point is that if the server isn't > responding, we want to give you the option to go choose some other > account. The context there is that we're in the initial fetch, so > showing the loading screen, and as long as we're doing that > there's no other UI. > So yeah, I think basically we don't want to do any retrying here. > Instead we can kick you to the account-picker screen, with a toast > or something to indicate an error, and then you might manually > retry a time or two or you might bail and switch to some other > account. > And in particular if you didn't even want to be using that account > anymore -- maybe you even know that it's a server which is > permanently shut down, but it just happened to be the last one > you'd been using in the app and so it's the one we tried loading > data from on startup -- then you can go use whatever other account > you were actually opening the app to use. If we're in an initial fetch from an already active, logged-in account that we have cached data for, though, we might as well take the time to retry (still with the 60 second timeout) because the user will be seeing a useful, interactive UI. [1] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/Stuck.20on.20loading.20screen/near/1178689

A `TimeoutError` will be handled the same way other errors in `fetchMessages` are handled; if it's a timeout in the fetch `ChatScreen` does on mount, `ChatScreen` will show the `FetchError` component we set up in zulip#4205. There's also been a passing mention on CZO of doing a timeout like this [1]: > After a long time, probably like a minute, we'll want that [...] > fetch to time out and fail in any case. [1] https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/.23M4156.20Message.20List.20placeholders/near/950853

And add that message and the existing message to messages_en.json; looks like we forgot to add the existing one.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Time out initial fetch and go to account-picker screen. #4754

Time out initial fetch and go to account-picker screen. #4754

Commits on Jul 16, 2021