Simplified local echo, with retry

[gnprice]

Background

This is a new proposed spec for handling the same user need as the following previous issue:

• Await send request; handle failure #720

The point is to better handle the case where you type out a message and hit send, and it fails because you don't have working network at that moment. The current behavior is pretty unpleasant when it hits: the message you wrote is just gone.

Our previous plan, described in #720, didn't work out (#720 (comment)). I think ultimately the way to solve this will be to have local echo #576, showing the still-being-sent message in the message list, along with an outbox system #133 for retrying send. But doing local echo in full will be a substantial task, and an outbox system is tricky to get right.

So, for launch, here's a simplified approach.

Spec

• We do a limited, placeholder, form of local echo: just show something like "(Sending message…)" where the message's content would go. (Or maybe the message source, as plain text.) This bypasses all the work of interpreting Zulip Markdown.

  To avoid this causing an annoying flicker whenever you actually do have a good connection to the server, we'll put this on a debounce timer: it only appears once it's been perhaps 300ms since the start of the send request, or sooner if the send request fails (as described below).

  (This part is anticipated in Local echo when sending messages #576 as one of the interim options there.)

• Then if a message fails to send, we show on the local-echo placeholder an option that lets you recover it. (Similarly perhaps if it's been a while, like 10s, since trying to send and the request hasn't completed one way or another.)

  You might want to retry sending, or just copy the text to save elsewhere. To cover both options, it can take the text and just put it back in the compose box. (If there's already something there, the recovered message can go at the end, leaving the user the choice of what to do.) The placeholder in the message list then disappears.

  This is a bit like the sort of outbox system described in Implement outbox system #133. It's simpler because there's no internal retry, which cuts out the should-send state and all its edges. An outbox-message starts at sending; goes to sent or failed; then gets removed.

Design

We don't have an exact design for this in Figma. See the existing designs for editing a message:
https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=4010-6347&m=dev

See also discussion at #mobile > handle failed send @ 💬; and use #mobile-design for discussing design questions that arise.

Implementation

The data structures for the outstanding send requests will live on the message store. Like with other data there, that means the data structures will be fields on MessageStoreImpl, exposed via methods on MessageStore, so that code elsewhere in the app invokes the methods directly on the PerAccountStore.

(The existing method sendMessage should move from PerAccountStore to MessageStore.)

For a state diagram of the behavior of each send request, see #mobile > handle failed send @ 💬.

References

• Previous issue: Await send request; handle failure #720
• Related issues (for more-expansive versions of the different parts of this plan):
  Local echo when sending messages #576
  Implement outbox system #133
• #mobile > handle failed send @ 💬