[Due for payment 2026-07-21] LHN - Marking an unread message as unread does not mark the conversation as unread

[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.4.26-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/62923718/folder/13176910/41237480/1534027983?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/n
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 15.4.1 Safari
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Go to https://staging.new.expensify.com
2. Navigate to a unread conversation with some history
3. Mark a new message as unread
4. Navigate away from the conversation

Expected Result:

The conversation is marked as unread
When navigating back to the conversation, the new message marker is still displayed on top of the message

Actual Result:

Marking an unread message as unread does not mark the conversation as unread, the new message marker is not displayed on top of the message

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7196919_1782938354688.Recording__2483.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7196919

Issue Owner

Current Issue Owner: @VickyStash

[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/296d56b2dd68bc99ba5cb911039c102f5f7f619530cf043575a91519fee93b54

[melvin-bot]

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

🤖 Automated deploy-blocker analysis — confidence: High (root cause verified by diffing the production branch against staging).

TL;DR: This is a regression introduced by #94817 (Decompose ReportActionsList: 11, merged 2026-06-30). It removed the block in useUnreadMarker that re-seeds the unread-marker cutoff when the hook instance is reused for a different report. Recommended fix: revert #94817.

What is the root cause of that problem?

useUnreadMarker keeps the marker cutoff in local state unreadMarkerTime, seeded from the report's lastReadTime. Because the report view / hook instance is reused across report switches, there was a block that re-seeded unreadMarkerTime from the current report's lastReadTime whenever reportID changed:

const [trackedReportID, setTrackedReportID] = useState(reportID);
if (trackedReportID !== reportID) {
    setTrackedReportID(reportID);
    setUnreadMarkerTime(reportLastReadTime); // re-seed on report switch
}

#94817 deleted this block (its only functional change; the author's new test assumes "one mount per report", which is not true when the instance is reused). After deletion, on navigating away and back:

1. Marking a message unread lowers lastReadTime in Onyx and emits unreadAction_…; the listener updates the marker on the currently mounted report, so it briefly shows. ✅
2. Navigating away reuses the same hook instance with a new reportID, but unreadMarkerTime is no longer re-seeded — it keeps the old value, and the "push down to newest" branch (useUnreadMarker.ts:139) advances it to the most recent action.
3. On returning, the cutoff is stale/too-new, so getUnreadMarkerReportAction finds nothing before it → the "New" divider is gone and the conversation no longer reads as unread. ❌

Why this PR (and why it's staging-only) — verification

• The re-seed block exists on production (useUnreadMarker.ts:51-54) but is absent on staging (e3b4f3c) — exactly matching "Reproducible in staging: Yes / production: No".
• Decompose ReportActionsList: 11 #94817 merged 2026-06-30, inside the 9.4.26 staging window; only functional file is src/hooks/useUnreadMarker.ts (rest of the diff is tests/JSDoc).
• Ruled out: the self-authored suppression in ReportUtils.isUnread() and shouldDisplayNewMarkerOnReportAction is already on production, so it can't cause a staging-only regression. That logic is the cause of the separate, production-reproducible [$250] Chat - The new message marker isn't displayed when user marks their own message as unread #94794 (own-message marker) — not this issue.

Key refs (SHA e3b4f3c): markCommentAsUnread (writes lastReadTime correctly — not the culprit), useUnreadMarker.

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

Revert #94817 — it is a self-contained decompose/refactor and reverting cleanly restores the per-report re-seed.

If a roll-forward is preferred over a revert, re-add the trackedReportID guard so unreadMarkerTime is re-seeded from the current report's lastReadTime whenever reportID changes.

What alternative solutions did you explore? (Optional)

Considered the self-authored isUnread suppression (#91940) as the cause but ruled it out — it is already in production.

Related issues

• [$250] Chat - The new message marker isn't displayed when user marks their own message as unread #94794 — new-message marker not shown for own messages (reproducible in production; different root cause — the self-authored gate). Not this bug, but adjacent.

---

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