This is just a race condition we need to resolve with the lazy body loading. The problem is if we start a fetch for snippets, then open a message before that happens, the snippet can finish and add a body, and then a second body request happens and adds that one too. We just need to check to make sure we didn't already grab the body.
To triagers: This should be pretty rare, but on slow connections, it might be easier to end up in this situation. To experience this bug, the user would have to scroll to see some messages in the list that they never saw before, and then click on a message before the snippet loads.
We need more info on frequency in field to understand how severe this is. How slow would a network connection have to be before this becomes intrusive?
I thought I'd posted an update to this, but it turns out I never hit the submit button. Oops. Anyway, this should only happen occasionally, and most likely during the first few times the user runs the email app (afterwards, we'll have most of the bodies anyway). It's hard to get useful numbers, since this varies so much, but I'd say that on an average connection, you'd have to click on a message less than one second after you stopped scrolling in order to see this. For slow connections with big emails, it might be easier to hit this, but I don't think it would happen terribly often... It would be a little annoying, but it doesn't really break anything. Hitting back and retrying should always fix the issue.
I'm reasonably sure this is fixed. Andrew: any thoughts? Either way, I'm not actively working on it.
Yeah, I'm pretty confident the invariants on the message reader got cleaned up as it relates to rebuilds.