Switching to an unread channel sometimes gets stuck at "Loading..."

Note: Also cherry-picked to v5.15.3 for dot release. Verified (as well as possible on a fresh server) on v5.15.3-rc1.

Verified on v5.16.2-rc1 test server using a couple users and hundreds of posts back and forth that the issue was not seen (Chrome). We also let the changes soak on master for a few days on community-daily and a few people tested, myself included (Mac desktop app), and the issue was no longer seen.

And this was cherry-picked to v5.17, and I am no longer seeing the issue on release branch either (Chrome and desktop app). Closing this ticket. PRs labeled; no new tests needed.

After confirming the root cause with , we agreed to let Apps team triage the fix here.

If this helps at all I seem to regularly encounter it when navigating through unreads using keyboard shortcuts — i.e., ⌘⇧⇡or⇣ —

I believe my analysis above was flawed – there are a lot of moving parts here -- but ultimately pointed me at something I’ve been able to reliably reproduce, and that correlates with the HAR files.

First, sometimes the client is expecting an old LastViewedAt (which gets pinned as unreadChunkTimeStamp in the state of the PostView component), but the server call to /api/v4/users/*/channels/*/posts/unread returns a recent chunk instead. I believe this occurs because instead of accepting a timestamp, the /posts/unread endpoint looks up the LastViewedAt for the corresponding ChannelMember -- but as part of switching to the channel, the client is simultaneously hitting the /api/v4/channels/members/me/ to mark the channel as read and update this very LastViewedAt property. If this completes before the /posts/unread API looks up the information, the wrong chunk is returned, and the client rejects the chunk given the timestamp mismatch, but then finds no other chunk to use, and just sits idle.

I’m going to sync up with to figure out where to take this one, as there’s no obviously clear fix.