1. Open Mattermost in two browsers as two separate users. Make sure that caching is enabled (and possibly close the browser's dev tools)
2. Have both users join the same channel
3. Have the first user make a post in the channel (clears the etag cache), switch channels away, switch channels back (triggers an empty getPostsSince to cache 0, but doesn't return an etag), and then refresh the page (calls getPosts to save the etag in the browser).
4. Have the second user repeat the same process of making a post, switching away, switching back, and then refreshing the page.
5. Have the first user refresh the page. The first user should be missing the second user's post, although they may be missing more if a 0 etag was previously cached.
Observed: You may see an older version of the posts in the channel
Expected: You see the latest version of the posts in the channel
Happens on community-daily, community
Using steps provided by HH I am unable to repo the bug. Also performed brief exploratory testing with additional users. I am always shown the most current version of the channel contents.
Tested and passed on 5.12.4-rc1 Channel content stays current.
5.13 testing is still needed.
Tested and passed on v5.13-rc3.
Was never able to repro the messages going missing in the UI, but tested according to HH's post:
When doing the steps where you post, change channels, change back, and then refresh, watch the network tab. When you refresh, you should see a request to /api/v4/posts/<channelId>. If you click on it, there should be a Response headers section containing an etag field. If that etag ever reads 188.8.131.52, then it's in a bad state where the bug can occur. If it says anything like 184.108.40.2062412324 where there's another number at the end of it, that's fine
Using those steps, I could repro the bug state on community on v5.12.2, and after several tries verified it did not reproduce on rc.test v5.13-rc3.
Same results as Linda when testing on 5.12.3 - I was not able to repo the actual bug to repo.
I did do alot of testing on 5.12.4 to ensure the channel stayed current and did validate that the state of the etags has been corrected as outlined in the comment above.
Closing (see previous comments from DH and me). No new tests needed; PRs labeled.