"No messages" when in fact we're loading messages

[gnprice]

This is perhaps the most conspicuous bug I regularly see at present when using the app. I see it on v26.20.143, and I think I've been seeing it on previous versions for weeks at least, perhaps longer.

The typical sequence is:

• You had the app open, and had been looking at some narrow.
• You go do something else, and come back to the app after a while -- like over 10 min. (The time for an event queue to expire.)
• You re-open the app; it was still in the background, so still has its navigation state and shows you that narrow.
• But for a few seconds, the message list in the narrow says "No messages! Why not start the conversation?", before switching to the "loading" animation.

I think basically what's going on is:

• We try to poll the event queue, and learn it's expired.
• OK, so we go and set up a new event queue, which will come with a new snapshot of all the data.
• Along with that, we have to discard all our existing message data as stale -- any of those messages could have been edited, deleted, had reactions added or removed, etc., since we last polled the queue, and we wouldn't know.
• But we do that in a way that leaves us acting as if we knew there were no messages in those narrows, etc. This might be as simple as an ordering issue; e.g. perhaps we shouldn't discard the message data at DEAD_QUEUE (when we learn the event queue has expired), but at REALM_INIT (kind of misnamed; dispatched when the new /register completes.)

Some history (which I haven't fully reread and absorbed) for cross-reference:

• "No messages" when there are messages #3162 was a previous bug with some similar symptoms -- much worse, though, as it doesn't just fix itself after a few seconds
• Invalidate old messages less abruptly (was: Fixes 'No messages' on queue restart) #3151 was meant to address that; the PR is open, but the "No messages" when there are messages #3162 part of it was merged
• "No messages" on following a notification #3284 was similar to the current bug, though a different repro sequence (involving a notification)
• Complicated loading sequence on following a notification #3319 described the symptoms in detail (though again the repro involves a notification)

See also chat discussion. There's an issue affecting MessageReactionList, where state.messages has no message with the expected message ID, which potentially is how the same underlying issue shows up if in step 1 you were looking at a reaction list rather than a message list.