[Due for payment 2026-07-13] [$250] Chat - Unread marker is not displayed when receiving messages on a new conversation.

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.99-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91179
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Chat Report View

Action Performed:

Prerequisite: No existing conversation between User A and User B.

1. Open the staging.new.expensify.com website as User A.
2. Start a conversation with User B.
3. Send 5+ messages to User B.
4. As User B, note that the new conversation is displayed bold in LHN, as it has unread messages.
5. Open chat with User A.
6. Note that no "New" marker is visible above the first received message.

Expected Result:

Unread marker should be visible above the first new received message after opening conversation.

Actual Result:

After receiving messages on a new conversation and opening chat, "New" marker is not visible above the first message.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7171376_1780565473039.Unread.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7171376

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062518909510019837
• Upwork Job ID: 2062518909510019837
• Last Price Increase: 2026-06-11

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/71e0e856e449816f559c4ac14dda28a7eb38f48615a3b6a3d4e3f94e163d4312

[MelvinBot]

Proposal

Confidence: medium. The mechanism below is fully supported by code, but it hinges on one runtime assumption (a brand‑new report has an empty lastReadTime at the moment it's opened) that should be confirmed before implementing — see the note at the end.

What is the root cause of that problem?

For a brand‑new conversation, report.lastReadTime is still empty when User B opens it (the report has never been read — which is also why it shows bold/unread in the LHN). The "New" marker is placed correctly for one render, then immediately cleared by the auto‑read‑on‑open flow:

1. On open, useUnreadMarker seeds unreadMarkerTime from the empty lastReadTime. With an empty time, every non‑created action counts as unread (isReportActionUnread returns !isCreatedAction), so the scan correctly places the marker above the first received message.
2. Opening the report is "caught up" (all 5 messages fit on screen), so useMarkAsRead fires readNewestAction, which optimistically writes report.lastReadTime = now.
3. useUnreadMarker's "empty → real value" hydration at useUnreadMarker.ts:56‑58 sees lastReadTime go from '' to now and pushes unreadMarkerTime to now. Now every message is "read" → the scan returns nothing → the marker disappears.

There is no pagination anchor to rescue it: usePaginatedReportActions returns no oldestUnreadReportAction when the initial lastReadTime snapshot is empty (if (!initialLastReadTime ...) return undefined).

For an existing conversation this never happens: lastReadTime is already non‑empty, so the empty→value hydration never fires and unreadMarkerTime stays at the prior read time, keeping the marker visible.

Why this is not the recent useUnreadMarker refactor (PR #91179)

This issue was caught during QA of #91179, but the bug is pre‑existing (the report says it reproduces in production). That PR only changed own‑message marker handling and moved the pushdown from a useLayoutEffect to an inline check — the received‑message path, the empty→value hydration, and the missing‑anchor‑on‑empty‑lastReadTime behavior are all identical before and after. The "reproducible in production: Yes" flag is consistent with a pre‑existing bug.

What changes do you think we should make in order to solve the problem?

Give the marker a stable anchor that survives the on‑open auto‑read when lastReadTime starts empty. Preferred:

• In usePaginatedReportActions, when the initial lastReadTime snapshot is empty but the report is unread, derive the oldest‑unread anchor from the first non‑created action (mirroring isReportActionUnread's empty‑lastReadTime semantics) instead of returning undefined. A stable oldestUnreadReportAction keeps the marker pinned via the existing anchor path even after readNewestAction writes lastReadTime = now.

Alternatively (or additionally), make the empty→value hydration in useUnreadMarker.ts:56‑58 ignore a lastReadTime that was just produced by our own on‑open readNewestAction (e.g. don't advance unreadMarkerTime past actions that were already unread at mount).

What alternative solutions did you explore? (Optional)

Seed unreadMarkerTime with the report's oldest action / created‑action time when lastReadTime is empty, so the later hydration to now no longer jumps past the unread messages.

Note on the one assumption to confirm

The whole chain depends on a brand‑new report having an empty report.lastReadTime at open time. Quick way to confirm: open a fresh conversation and log report.lastReadTime on the first render of ReportActionsList (before readNewestAction fires). If it is non‑empty (e.g. set to the report's created time), the root cause shifts and the fix should target the anchor computation only.

Possibly related (unread‑marker family, but distinct): #44647, #12249.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92673) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When User B receives the first messages on a brand‑new conversation (one that didn't exist before), the chat shows as unread/bold in the LHN, but opening it shows no "New" unread marker above the first received message.

What is the root cause of that problem?

The "New" marker on first open is driven by two mechanisms in useUnreadMarker, and for a brand‑new conversation both fail because the report's lastReadTime is empty.

When User B receives a never‑seen‑before conversation, report.lastReadTime is empty. That's exactly why it renders bold in the LHN — isUnread short‑circuits to true on an empty lastReadTime:

https://github.com/Expensify/App/blob/753ada2f46f/src/libs/ReportUtils.ts#L9046-L9048

But that same empty lastReadTime breaks the marker. The persistent marker mechanism is the oldestUnreadReportAction anchor — it's snapshotted once at first render and is what keeps the marker pinned above the first unread message (even after mark‑as‑read fires). It's computed in usePaginatedReportActions, and it early‑returns undefined whenever lastReadTime is falsy:

https://github.com/Expensify/App/blob/753ada2f46f/src/hooks/usePaginatedReportActions.ts#L63-L68

So for a new conversation oldestUnreadReportAction is undefined, and in useUnreadMarker the stable anchor branch is skipped entirely (it requires a non‑null oldestUnreadReportActionID):

https://github.com/Expensify/App/blob/753ada2f46f/src/hooks/useUnreadMarker.ts#L96-L117

That leaves only the fallback scan (getUnreadMarkerReportAction). The scan does treat every non‑CREATED action as unread when unreadMarkerTime is empty (isReportActionUnread returns !isCreatedAction for an empty time):

https://github.com/Expensify/App/blob/753ada2f46f/src/libs/ReportActionsUtils.ts#L2473-L2479

…but on first open all the freshly‑loaded messages are "new" (not present in the previous render snapshot), so shouldDisplayNewMarkerOnReportAction suppresses the marker for them via the isNewMessage guard, and then mark‑as‑read pushes unreadMarkerTime to the newest action — so the scan finds nothing either:

https://github.com/Expensify/App/blob/753ada2f46f/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts#L68-L85

Why existing conversations don't hit this: they have a non‑empty lastReadTime, so oldestUnreadReportAction resolves to the oldest unread action and the stable anchor branch shows/keeps the marker — the fallback scan's isNewMessage suppression never matters. The bug is specific to the empty‑lastReadTime (brand‑new conversation) case, which is why it reproduces on every platform regardless of the QA device.

What changes do you think we should make in order to solve the problem?

Make the oldestUnreadReportAction anchor handle an empty lastReadTime instead of bailing out. When lastReadTime is empty, every non‑CREATED action is unread, so the oldest unread action is simply the oldest non‑CREATED action. We can express both cases with the existing isReportActionUnread helper, whose lastReadTime‑empty branch already encodes exactly this rule — keeping us consistent with the rest of the marker logic.

-        const initialLastReadTime = initialReportLastReadTime.current;
-        if (!initialLastReadTime || !sortedAllReportActions?.length) {
-            return undefined;
-        }
-
-        return sortedAllReportActions.findLast((reportAction) => reportAction.created > initialLastReadTime)?.reportActionID;
+        const initialLastReadTime = initialReportLastReadTime.current;
+        if (!sortedAllReportActions?.length) {
+            return undefined;
+        }
+
+        // When lastReadTime is empty (e.g. a brand-new conversation), every non-CREATED action is unread,
+        // so anchor to the oldest unread one instead of bailing out and losing the unread marker entirely.
+        return sortedAllReportActions.findLast((reportAction) => isReportActionUnread(reportAction, initialLastReadTime))?.reportActionID;

Supporting change: add isReportActionUnread to the existing @libs/ReportActionsUtils import in usePaginatedReportActions.ts (line 5).

Why this is safe:

• For an existing conversation (non‑empty lastReadTime), isReportActionUnread(a, t) is equivalent to the previous a.created > t predicate (with extra null‑guards on created), so behavior is unchanged — no regression to the working case.
• For the empty case, findLast over the descending sortedAllReportActions returns the oldest unread action, and isReportActionUnread returns false for the CREATED action, so we never anchor the marker above the "chat created" system message.
• Offline: unaffected — the offline path (earliestReceivedOfflineMessageIndex / wasMessageReceivedWhileOffline) and unreadMarkerTime handling in useUnreadMarker are untouched; this change only restores the anchor that those paths feed into.
• Once oldestUnreadReportAction resolves, the existing stable‑anchor branch in useUnreadMarker (L96‑L117) keeps the marker pinned above the first received message even after mark‑as‑read fires — matching the existing‑conversation behavior.

What alternative solutions did you explore? (Optional)

• Relax the isNewMessage suppression in shouldDisplayNewMarkerOnReportAction so the fallback scan shows the marker for fresh messages. Rejected: that guard deliberately prevents a "New" marker from popping onto messages arriving in real time while you're already at the bottom of the chat; loosening it would regress that case, and the scan would still get wiped by mark‑as‑read. Fixing the anchor is both narrower and the mechanism actually responsible for the persistent marker.
• Default an empty lastReadTime to the report's creation time at the report layer. Rejected: it's a much broader change touching unread/LHN semantics across the app (isUnread intentionally treats empty lastReadTime as unread) with high regression risk, to fix a marker‑specific symptom.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

shouldDisplayNewMarkerOnReportAction returns false for User A's messages because they're treated as "newly added" on the render where User B's actions paginate in for the first time. The gate that's supposed to suppress marker flicker for messages-arriving-while-watching also fires for messages-paginating-in-on-open.

The gate is at the bottom of the function:

https://github.com/Expensify/App/blob/main/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts#L68-L85

// If no unread marker exists, don't set an unread marker for newly added messages from the current user.
const isFromCurrentUser = currentUserAccountID === (isReportPreviewAction(message) ? message.childLastActorAccountID : message.actorAccountID);
const isNewMessage = !prevSortedVisibleReportActionsObjects[message.reportActionID];
...
if (isFromCurrentUser) {
    return !shouldIgnoreUnreadForCurrentUserMessage;
}

return !isNewMessage || isScrolledOverThreshold;

The comment says "don't set an unread marker for newly added messages from the current user" — that's the isFromCurrentUser branch, which has its own guard via shouldIgnoreUnreadForCurrentUserMessage. The other branch (final return), reached for messages not from the current user, also consults isNewMessage — but isNewMessage is computed purely from "was this action in prevSortedVisibleReportActionsObjects?", with no distinction between:

1. A message that arrived while the user was already in the chat (the live-arrival case the gate is designed for — keep the marker pinned on the first existing unread, not on the just-arrived one).
2. Actions that paginate in for the first time when the user opens a chat (every action looks "new" because the previous render had no actions yet).

Case (2) is exactly the QA's reproduction. Trace for User B opening the chat with User A:

1. User B taps the chat from the LHN → ReportScreen mounts.
2. useUnreadMarker runs. sortedVisibleReportActions is empty (or only the CREATED action — actions haven't paginated yet). usePrevious(sortedVisibleReportActionsObjects) returns the current empty value on first render, so prevSortedVisibleReportActionsObjects === {}. No marker yet (no actions to mark).
3. The pagination request resolves and User A's messages land in Onyx. sortedVisibleReportActions is now populated.
4. Re-render. prevSortedVisibleReportActionsObjects is now the stale {} from step 2. For each of User A's messages: prevSortedVisibleReportActionsObjects[message.reportActionID] === undefined → isNewMessage = true.
5. For each action: isFromCurrentUser = false (User A sent them, not User B), so we fall to the final return.
6. !isNewMessage || isScrolledOverThreshold → !true || false → false. No marker.
7. The user sees the messages, no "New" line, even though the LHN still shows the conversation bold because lastReadTime is older than the new actions.

getUnreadMarkerReportAction walks every visible action and asks shouldDisplayNewMarkerOnReportAction. None return true, so the scan returns [null, -1], and unreadMarkerReportActionID is null. The shouldDisplayNewMarker={reportAction.reportActionID === unreadMarkerReportActionID} check at the row level:

https://github.com/Expensify/App/blob/main/src/pages/inbox/report/ReportActionsList.tsx#L538

…never matches.

The fallback path oldestUnreadReportActionMarker (at lines 94-101 of useUnreadMarker.ts) would normally rescue this case — it directly anchors the marker to the server-provided oldestUnreadReportActionID on first open:

https://github.com/Expensify/App/blob/main/src/hooks/useUnreadMarker.ts#L94-L101

let oldestUnreadReportActionMarker: [string, number] | undefined;
if (oldestUnreadReportActionID && !hasOnceLoadedReportActions) {
    const visibleIndex = sortedVisibleReportActions.findIndex((action) => action.reportActionID === oldestUnreadReportActionID);
    if (visibleIndex >= 0) {
        oldestUnreadReportActionMarker = [oldestUnreadReportActionID, visibleIndex];
    }
}

…but this only fires when oldestUnreadReportActionID is set on the report. For a brand-new conversation where User B has never opened it before, the server doesn't necessarily have a pre-computed oldestUnreadReportActionID (the field is set by the OpenReport flow once a conversation has prior reads; a never-opened conversation has no such anchor). When that ID is absent, the scan-based logic is the only path, and the scan returns null because of the gate above.

This isn't a regression introduced by PR #91179 — the gate has the same shape pre-decomposition. PR #91179's QA happened to surface it because the test plan deliberately exercises the "no existing conversation" precondition that bypasses the oldestUnreadReportActionID fallback.

What changes do you think we should make in order to solve the problem?

The isNewMessage gate should only fire when an action genuinely just arrived, not when it's part of the initial pagination of an already-existing conversation. The cleanest distinguisher available in the hook is hasOnceLoadedReportActions — false on the first pagination, true thereafter — and it's already plumbed into useUnreadMarker.

Thread it through:

  // src/hooks/useUnreadMarker.ts
  const scanned = getUnreadMarkerReportAction({
      visibleReportActions: sortedVisibleReportActions,
      earliestReceivedOfflineMessageIndex,
      currentUserAccountID,
      prevSortedVisibleReportActionsObjects,
      unreadMarkerTime,
      isScrolledOverThreshold,
      isOffline,
      isReversed: false,
      isAnonymousUser,
+     hasOnceLoadedReportActions,
  });

  // src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts
  type ShouldDisplayNewMarkerOnReportActionParams = {
      message: OnyxTypes.ReportAction;
      nextMessage: OnyxTypes.ReportAction | undefined;
      isEarliestReceivedOfflineMessage: boolean;
      unreadMarkerTime: string | undefined;
      currentUserAccountID: number;
      prevSortedVisibleReportActionsObjects: Record<string, OnyxTypes.ReportAction>;
      isScrolledOverThreshold: boolean;
      isOffline: boolean;
+     /** Whether the report actions have been loaded at least once. False during the first pagination
+      *  after opening the chat — used to distinguish initial-load "new" actions from live arrivals. */
+     hasOnceLoadedReportActions: boolean;
  };

  const shouldDisplayNewMarkerOnReportAction = ({
      message,
      nextMessage,
      isEarliestReceivedOfflineMessage,
      unreadMarkerTime,
      currentUserAccountID,
      prevSortedVisibleReportActionsObjects,
      isScrolledOverThreshold,
      isOffline,
+     hasOnceLoadedReportActions,
  }: ShouldDisplayNewMarkerOnReportActionParams): boolean => {
      ...
      if (isFromCurrentUser) {
          return !shouldIgnoreUnreadForCurrentUserMessage;
      }

-     return !isNewMessage || isScrolledOverThreshold;
+     // Suppress the marker for live-arriving actions only — not for actions that are paginating in
+     // for the first time after the user opened the chat. On first load, every action looks "new"
+     // because the previous render had no actions; that's the QA's reproduction (new conversation,
+     // first open, no marker). Once `hasOnceLoadedReportActions` flips to true, the gate operates
+     // as before for messages arriving while the user is watching.
+     return !isNewMessage || isScrolledOverThreshold || !hasOnceLoadedReportActions;
  };

And in getUnreadMarkerReportAction (same file), accept and forward hasOnceLoadedReportActions:

  type GetUnreadMarkerReportActionParams = {
      visibleReportActions: OnyxTypes.ReportAction[];
      earliestReceivedOfflineMessageIndex: number | undefined;
      currentUserAccountID: number;
      prevSortedVisibleReportActionsObjects: OnyxTypes.ReportActions;
      unreadMarkerTime: string | undefined;
      isScrolledOverThreshold: boolean;
      isOffline: boolean;
      isReversed: boolean;
      isAnonymousUser?: boolean;
+     hasOnceLoadedReportActions: boolean;
  };

  const getUnreadMarkerReportAction = ({
      ...,
+     hasOnceLoadedReportActions,
  }) => {
      ...
      const shouldShowMarker =
          reportAction &&
          shouldDisplayNewMarkerOnReportAction({
              ...
+             hasOnceLoadedReportActions,
          });
      ...
  };

After this:

• First open (the QA case): hasOnceLoadedReportActions=false, the final return becomes !isNewMessage || isScrolledOverThreshold || true → true. The first unread action shows the marker. The next-action-also-unread short-circuit at line 60 still ensures the marker pins to the earliest unread action (subsequent unreads aren't marked).
• Live arrival while in chat: hasOnceLoadedReportActions=true, behavior unchanged.
• Returning to a chat with oldestUnreadReportActionID: the useUnreadMarker.ts early-return branch at lines 96-101 still works as a faster path; this change only fixes the fall-through scan.

A complementary test to add in tests/unit/useUnreadMarkerTest.ts: build a brand-new conversation scenario where the user has no prior lastReadTime, no oldestUnreadReportActionID, and three actions paginate in for the first time. Assert that the first action is returned as the marker. That test would catch this exact regression class going forward.

What alternative solutions did you explore? (Optional)

I considered checking whether the message's created time was older than "a few seconds ago" to distinguish pagination-arrivals from live-arrivals — but message clocks aren't reliable for this (client/server skew, replayed messages from offline), and the threshold would be a magic number. hasOnceLoadedReportActions is exactly the signal we want and is already available in the hook with the right semantics. I also looked at extending the oldestUnreadReportActionMarker fallback in useUnreadMarker.ts to derive its own anchor when oldestUnreadReportActionID is absent — that's basically reinventing the scan with an extra rule, where the cleanest fix is letting the scan itself know it's the first load.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Ollyws (External)

[kamronbek04]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When User B opens a brand-new conversation that already contains unread messages received from User A while it was closed, the "New" unread marker never appears above the first received message. The LHN correctly shows the chat as bold/unread, but inside the report there's no marker, so the user has no visual anchor for where the new messages begin.

What is the root cause of that problem?

The marker that's shown above the oldest unread message is decided per report action by shouldDisplayNewMarkerOnReportAction. For a message from another user, the final decision is this line:

https://github.com/Expensify/App/blob/main/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts#L72-L90

const isNewMessage = !prevSortedVisibleReportActionsObjects[message.reportActionID];
...
if (isFromCurrentUser) {
    return !shouldIgnoreUnreadForCurrentUserMessage;
}
return !isNewMessage || scrollingVerticalOffset >= CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD;

isNewMessage is meant to mean "a message that just arrived live," and the scrollingVerticalOffset check suppresses the marker when such a message arrives while you're already scrolled to the bottom (you're watching it land, so no marker is needed). The problem is how isNewMessage is derived: it's true for any action absent from the previous render's snapshot (prevSortedVisibleReportActionsObjects, a usePrevious value).

When you open a chat, ReportActionsList mounts fresh, so on the first render that has actions the previous snapshot is empty — every message is flagged isNewMessage = true. Opening a chat also lands you at the bottom, so scrollingVerticalOffset is 0, well under the 250 threshold. The expression therefore evaluates !true || 0 >= 250 → false for each of User A's messages, and the scan returns no marker.

Existing conversations don't show this because they're rescued by the server's oldest-unread pagination anchor (oldestUnreadReportAction), which ReportActionsList turns into a marker during the initial load window:

https://github.com/Expensify/App/blob/main/src/pages/inbox/report/ReportActionsList.tsx#L268-L306

But that anchor only exists when pagination links to the oldest unread action — it requires a resourceItem from usePaginatedReportActions, which a brand-new report received over Pusher doesn't have (oldestUnreadReportAction resolves to undefined). So a new conversation depends entirely on the scan, and the scan fails as shown above.

What makes it permanent is the follow-up effect that advances unreadMarkerTime whenever no marker is set:

https://github.com/Expensify/App/blob/main/src/pages/inbox/report/ReportActionsList.tsx#L411-L430

if (isAnonymousUser || unreadMarkerReportActionID) {
    return;
}
const mostRecentReportActionCreated = lastAction?.created ?? '';
if (mostRecentReportActionCreated <= unreadMarkerTime) {
    return;
}
setUnreadMarkerTime(mostRecentReportActionCreated);

Because the first-render scan produced unreadMarkerReportActionID === null, this effect fires and pushes unreadMarkerTime forward to the newest message's timestamp. From then on isReportActionUnread(message, unreadMarkerTime) is false for every message, so even once the previous-render snapshot fills in (which would otherwise make isNewMessage false and let the marker show), the marker can never reappear. The conversation is now treated as fully read despite the user never having seen the messages.

What changes do you think we should make in order to solve the problem?

The at-bottom suppression should apply to genuine live arrivals, not to the initial batch of unread messages shown when the report first opens. The initial population is exactly the case where the previous-render snapshot is empty — so we can detect it and skip the suppression for it. That single change also keeps unreadMarkerReportActionID non-null on the first render, which prevents the unreadMarkerTime-advancing effect (gated on a null marker) from poisoning the state.

     // If no unread marker exists, don't set an unread marker for newly added messages from the current user.
     const isFromCurrentUser = currentUserAccountID === (isReportPreviewAction(message) ? message.childLastActorAccountID : message.actorAccountID);
     const isNewMessage = !prevSortedVisibleReportActionsObjects[message.reportActionID];
+    // On the first render that has actions (e.g. opening a conversation with a backlog of unread
+    // messages received while it was closed), the previous-render snapshot is empty so every message
+    // looks "new". These aren't live arrivals, so the at-bottom suppression below must not hide the
+    // marker for them — otherwise a freshly-opened unread conversation shows no "New" marker at all.
+    const isInitialPopulation = isEmptyObject(prevSortedVisibleReportActionsObjects);
     ...
     if (isFromCurrentUser) {
         return !shouldIgnoreUnreadForCurrentUserMessage;
     }

-    return !isNewMessage || scrollingVerticalOffset >= CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD;
+    return !isNewMessage || isInitialPopulation || scrollingVerticalOffset >= CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD;

(isEmptyObject from @src/types/utils/EmptyObject, or equivalently Object.keys(prevSortedVisibleReportActionsObjects).length === 0.)

On the first render the oldest unread message from another user now passes, the scan returns its reportActionID, unreadMarkerReportActionID is set, the time-advancing effect short-circuits, and the marker stays put. After the first render the previous snapshot is populated, so isNewMessage is false for already-shown messages and the live-arrival suppression continues to work exactly as before — a message that truly arrives while you sit at the bottom still won't get a marker.

Scope boundary: the change only affects the very first render that contains actions; steady-state behavior, the current-user-message path (isFromCurrentUser), offline-received-message handling, and pagination anchoring are untouched. Note that on main this scan and the time-advancing effect now live in the useUnreadMarker hook (extracted in #91179, the PR this was caught under), but shouldDisplayNewMarkerOnReportAction is unchanged by that extraction, so the same one-line fix applies. Test: with no prior conversation, have User A send 5+ messages to User B; as User B open the chat from a bold LHN row → the "New" marker should sit above User A's first message. Then, while staying at the bottom of an open chat, receive a new live message → it should not get a marker (regression check).

What alternative solutions did you explore? (Optional)

Guarding the unreadMarkerTime-advancing effect instead — only pushing the time forward when the report was already read up to near the latest action (genuine live catch-up) rather than when opening with a backlog. That stops the permanent poisoning, but on its own it doesn't make the first-render scan succeed, so the marker would still be missing until a later re-render; it treats the symptom (state poisoning) rather than the cause (the scan misclassifying the initial batch as live arrivals). I also considered populating oldestUnreadReportAction for newly-received conversations so the anchor path covers them, but that means changing usePaginatedReportActions / the pagination-resource contract for a case it was never built to anchor, which is a much larger and riskier change than correcting the per-action decision where the misclassification actually happens.

[moxw]

Proposal

What is the root cause of that problem?

This is caused by the unread marker boundary being overwritten when a brand-new unread report is opened.

In the refactored chat list code, useUnreadMarker initializes unreadMarkerTime from report.lastReadTime. For a new conversation that User B has never opened, report.lastReadTime is empty, which is the correct boundary for showing the marker above the first non-created message.

However, useMarkAsRead immediately calls readNewestAction() when the unread report is opened. That optimistically updates report.lastReadTime. Then useUnreadMarker runs this logic:

if (unreadMarkerTime === '' && reportLastReadTime !== '') {
    setUnreadMarkerTime(reportLastReadTime);
}

So the hook treats the local “mark as read on open” update as if it were initial data loading, advances unreadMarkerTime to the new read time, and getUnreadMarkerReportAction() no longer finds any unread action. Existing conversations usually do not hit this because their unreadMarkerTime starts with a non-empty previous lastReadTime.

What changes do you think we should make in order to solve the problem?

Update src/hooks/useUnreadMarker.ts so the unread marker boundary is frozen for the current report once an unread marker can be resolved.

Concretely:

1. Do not blindly sync unreadMarkerTime from live report.lastReadTime after report actions are already available.
2. Compute the scanned marker / oldest unread anchor first.
3. Only adopt a late non-empty reportLastReadTime when unreadMarkerTime is empty and there is no marker candidate / no oldest unread anchor. This keeps the existing “data loaded late” behavior without wiping the divider created by opening a new unread chat.
4. Move the render-time setUnreadMarkerTime() calls into useEffects so the hook does not update state while rendering.

Add a regression test in tests/unit/useUnreadMarkerTest.ts:

• Start with mockLastReadTime = '' and a visible message from another user.
• Assert the hook returns that message as unreadMarkerReportActionID.
• Rerender after changing mockLastReadTime to a later timestamp, simulating readNewestAction() on open.
• Assert the same unread marker is still returned.

Also keep/extend coverage for the late-data case where there are no unread actions/marker candidates and report.lastReadTime changes from empty to non-empty, so we do not regress the original safeguard.

What alternative solutions did you explore? (Optional)

Another option would be to make readNewestAction() emit a special event or pass metadata so useUnreadMarker can distinguish local “read on open” updates from server-loaded lastReadTime updates. That is more invasive than needed. The marker hook already owns the boundary state, so keeping that boundary stable until an explicit read/unread marker event is the smaller and safer fix.