You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the user scrolls to the earliest messages in a message list, we take that as a cue to fetch earlier messages if any. This issue is to tell the user when those fetches are failing so they can act on it, e.g. by not waiting longer or by debugging their network.
#945 is related, and we expect PR #1050 for that soon. Let's finish that before picking up this issue.
A toast or dialog won't be correct here because it would be too spammy. Even when throttled by a BackoffMachine (as in #1050), retries may be done multiple times per second.
How about a stateful marker (an ⚠ sign or similar) at the place where the user expects the fetched messages to appear. Like how we show the fetch's progress feedback:
One approach post-#1050 is to show the marker just during the cooldown period between retries. Let's not do that, for a few reasons:
When the requests take a short time before failing, this makes it more likely for the marker to flip on and off quickly, making the app seem glitchy. ("Is there a problem or not??")
When the requests take a long time before failing—could be 30s or more—the marker could be extremely easy to miss. The cooldown period could be only milliseconds, maybe even too short for a frame.
I propose showing the marker from the start of the first retry (i.e. the second request for the same batch of messages, after the first one failed) until a retry succeeds or the message list resets. If a request is in progress, of course we hope it succeeds…but if we've just made a request with the same params and it failed, we shouldn't be too optimistic. If that's the situation we're in, the marker can help set the user's expectations.
(I thought about having the marker appear with maybe the third or fourth retry. But that's actually not soon enough to be helpful, if each doomed request is taking 30s or more.)
For the implementation, assuming #1050, the condition for showing the marker could simply be _fetchOlderCooldownBackoffMachine?.waitsCompleted > 0.
I made a sketch of what the marker might look like:
or something, instead of just
The text was updated successfully, but these errors were encountered:
(Filing this issue from my thought at #1050 (review) .)
When the user scrolls to the earliest messages in a message list, we take that as a cue to fetch earlier messages if any. This issue is to tell the user when those fetches are failing so they can act on it, e.g. by not waiting longer or by debugging their network.
#945 is related, and we expect PR #1050 for that soon. Let's finish that before picking up this issue.
A toast or dialog won't be correct here because it would be too spammy. Even when throttled by a
BackoffMachine
(as in #1050), retries may be done multiple times per second.How about a stateful marker (an ⚠ sign or similar) at the place where the user expects the fetched messages to appear. Like how we show the fetch's progress feedback:
One approach post-#1050 is to show the marker just during the cooldown period between retries. Let's not do that, for a few reasons:
I propose showing the marker from the start of the first retry (i.e. the second request for the same batch of messages, after the first one failed) until a retry succeeds or the message list resets. If a request is in progress, of course we hope it succeeds…but if we've just made a request with the same params and it failed, we shouldn't be too optimistic. If that's the situation we're in, the marker can help set the user's expectations.
(I thought about having the marker appear with maybe the third or fourth retry. But that's actually not soon enough to be helpful, if each doomed request is taking 30s or more.)
For the implementation, assuming #1050, the condition for showing the marker could simply be
_fetchOlderCooldownBackoffMachine?.waitsCompleted > 0
.I made a sketch of what the marker might look like:
The text was updated successfully, but these errors were encountered: