Belated duplicate messages

[gnprice]

The other day a message I sent from the app (v26.0.123, I think, on Android) was sent promptly... and then nearly a week later it got sent again. (This was in PMs with @jainkuniya -- here's a link which he and I can see to look back at any details.)

Similarly, a user reports:

we've had issues where someone will hit their mobile app a couple hours later and all of a sudden it will "resend" the messages it sent before. This is not a frequent problem, but creates some confusion when it occurs.

Some details on the instance I saw:

• I believe I was using the app mostly in a test org in the intervening week, and not on chat.zulip.org where this message was. The second send happened shortly after I'd done a "switch account" back to chat.zulip.org.
• I wasn't looking at that PM thread at the time. Fortunately the message was harmless (and @jainkuniya immediately guessed that it was a double-post); but if it had caused confusion, I wouldn't necessarily have had any idea it had happened in order to try to clear things up.
• The original message is dated (by the server) a little under four minutes after the message it replies to, so that's an upper bound on how long it took the app to successfully send it the first time. IIRC the previous message was already a few minutes old when I sent my reply, so it may in fact have sent immediately.

One thing we should probably do in any case:

• After some time (an hour or two?) that a to-be-sent message has stuck around in the outbox, stop trying to send it. Sometimes late is worse than never (especially for very short messages like "Sure", "no", "OK" that can fit with different meanings into lots of contexts).
  • An ideal version of this would then have some clear indication to the user that it hadn't sent. But pending that, at some point it's better to silently drop the message than to silently finally send it.

Then in both the case I saw, and the user's report, there's the interesting fact that the message actually had gotten sent in the first place. That may point to a bug we can fix.

[gnprice]

See also the earlier issue #2374, which is very similar but without the long intervening delay.