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

Description

I've split this issue off of https://mattermost.atlassian.net/browse/MM-18576 to explicitly track the issues seen by and others where the network requests for the `/unreads` endpoint succeed, but the client appears to be stuck in an endless "Loading..." state.

Reproduction steps currently unknown.

QA Test Steps

See description

Activity

Show:
Jesse Hallam
October 12, 2019, 1:13 AM

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.

Steve Mudie
October 13, 2019, 6:08 PM

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

 

Jesse Hallam
October 15, 2019, 11:28 AM

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

Linda Mitchell
October 31, 2019, 12:16 AM

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.

Linda Mitchell
November 6, 2019, 9:36 AM

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.

Done

Mana

4

Assignee

Sudheer Timmaraju

QA Assignee

Steve Mudie

Reporter

Jesse Hallam

Epic Link

None

Mattermost Team

Core Features

Sprint

None

Labels

QA Testing Areas

Other (write in QA test steps)

GitHub Issue

None

Components

None

Severity

None
Configure