[v11.7.1] Channel reopens at a previous-day read post instead of the unread post after Mark as Unread

Troubleshooting
1

Summary

After upgrading from v10.9.1 to v11.7.1, reopening a channel after using
“Mark as Unread” restores the viewport to an older already-read post
instead of the unread post itself.
The unread state is preserved correctly (the “1 new message posted today”
banner appears), but the scroll restoration target is incorrect.
This behavior was not reported by our users on v10.9.1 and only began
after upgrading to v11.7.1.

Steps to reproduce

Environment

  • Edition: Mattermost Team Edition (custom build)
  • Server version: 11.7.1
    • Previous version on same install: 10.9.1
  • Client: Google Chrome on Windows
  • Database:
    PostgreSQL 13 → Amazon RDS PostgreSQL 16 during same upgrade
  • Search backend:
    PostgreSQL FTS + pg_bigm
  • MM_FEATUREFLAGS_CJKSEARCH=true
  • MM_SQLSETTINGS_QUERYTIMEOUT=120

Minimal deterministic repro

  1. Open a channel containing:
    • at least one already-read post from a previous day
    • at least one post from today
  2. Right-click today’s post and choose “Mark as Unread”.
  3. Confirm the banner appears at the top:

    “↓ Jump to recent messages | 1 new message posted today”
    This confirms the server correctly registered the unread state.

  4. Switch to another channel via the sidebar.
  5. Reopen the original channel.

Expected behavior

The unread post should appear at (or very near) the top of the viewport,
directly below the “New Messages” separator, as in v10.9.1.

Observed behavior

The channel reopens scrolled to a previous-day already-read post.
In our recording:

  • unread target post: today 13:23
  • restored viewport position: yesterday 15:16

The unread banner remains visible at the top, but the actual unread post
is below the fold and requires manual scrolling to reach.
The issue only reproduces when the channel contains at least one unread
message. With zero unread messages, reopening behaves correctly.

Regression context

The previously closed #33536 (v10.10.x, fixed via MM-64957 in 10.10.2 /
10.11) covered a related but narrower auto-scroll regression in DMs.
The same symptom resurfacing in v11.x via the broader “open unread
channel” path may indicate either:

  • the original fix was not carried into the v11 webapp /
    virtualized post list changes, or
  • a new scroll restoration path reintroduced the same anchor
    calculation issue.
2

Follow-up: behavior with “Start at newest” setting

A teammate reproduced the same issue with the user preference
“Scroll position when viewing an unread channel” set to
“Start me at the newest message” (the non-default option).

The result is interesting because it helps narrow down where the bug
actually occurs.

Observed behavior with “Start me at the newest message”

  1. Same repro steps: mark today’s post as unread, switch channels, then return.
  2. For a brief moment, the channel renders at exactly the same incorrect position seen with the default setting — an already-read post from the previous day. The “X new messages since yesterday” banner is visible.
  3. Approximately 0.3 seconds later, the banner changes from
    “↓ Jump to recent messages” to
    “↑ Jump to unread”, indicating that the viewport has already scrolled past the unread separator on its way to the newest message.
  4. The channel then settles on the most recent post, as intended by the setting.

With “Start me at the newest message”, the user only observes a brief flicker before the automatic jump corrects the position. With the default
“Start me where I left off” setting, however, no corrective jump occurs, leaving the user stranded at the incorrect scroll position — which matches the original report.

What this suggests

The initial scroll-restoration calculation appears to be incorrect
independently of the unreadScrollPosition preference.

The “Start me at the newest message” code path merely masks the issue because it performs a second scroll immediately after mount. However, the same incorrect initial anchor is still computed in both settings.

This also aligns with the original #35112 report that changing the advanced setting “does not fix or change the issue” — both settings initially restore to the same incorrect position, but only one of them subsequently scrolls away from it.