[$250] LHN-The conversation is marked as unread after navigating away

[mitarachim]

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?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176910/test-cases/41237477
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 26.5 Chrome, iPhone 15 iOS 26.5
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Open 1:1 chat with another user
2. Send a message from another user
3. Navigate away from the conversation and observe LHN
4. Open the chat

Expected Result:

The chat is not shown bold in LHN, when the message was read

Actual Result:

The chat is shown unread (bold) in LHN after receiving a message while in chat and navigating away from it. The message has a "New message" mark

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7196910_1782937692866.Unread.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072555997276765693
• Upwork Job ID: 2072555997276765693
• Last Price Increase: 2026-07-09

[MelvinBot]

Proposal

What is the root cause of that problem?

When a message arrives from the other user while you are actively viewing a 1:1 chat, the app decides whether to immediately mark it read in useMarkAsRead.ts. The read only happens if all of these are true at that instant (useMarkAsRead.ts:106):

shouldReadOnReportChange = ((isVisible && Visibility.hasFocus()) || isFromNotification) && !hasNewerActions && isScrolledToEnd

If any one is false, the read is skipped — it just sets a flag (useMarkAsRead.ts:117) and defers. The deferred read is only completed later by completeSkippedMarkAsRead, which requires the unread marker to scroll into view. But when a message lands while you're already at the bottom of the chat, no scroll happens, so that completion never fires. lastReadTime is never advanced past the new message, so isUnread stays true → the LHN row is bold and the "New message" marker sticks after you navigate away.

The most suspicious gate is !hasNewerActions. A live Pusher message can momentarily leave the report in a hasNewerActions === true state while pagination catches up, which skips the read even though the user is focused and at the bottom. This condition was added during the recent useMarkAsRead extraction (PR #92788 / "decompose ReportActionsList" series, first landed ~May 2026), and the older parallel copy in MoneyRequestReportActionsList.tsx does not have it — pointing to a regression.

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

When a new inbound action arrives while the report is visible, focused, and scrolled to the bottom, mark it read regardless of the transient hasNewerActions state. Concretely, in useMarkAsRead.ts:106:

• Drop (or relax) the !hasNewerActions requirement from shouldReadOnReportChange for the visible-and-focused case, so a message received while the user is actively viewing the newest actions is read immediately.
• Alternatively, add a fallback that runs completeSkippedMarkAsRead when the user is visible/focused and already at the bottom (i.e. don't depend solely on a scroll event to flush a skipped read), so the deferred path can't get stranded.

What alternative solutions did you explore? (Optional)

A second, less likely contributor is a timestamp race: readNewestAction writes lastReadTime = getDBTimeWithSkew() (client "now", Report/index.ts) while the message's lastVisibleActionCreated is a server timestamp; isUnread uses a strict < millisecond comparison, so a sub-second discrepancy could re-mark unread. This is worth ruling out but the skip-and-never-complete path above better explains the consistent reproduction.

Investigation details & evidence

• Real-time read effect and gate: useMarkAsRead.ts:95-123. The effect re-runs on report?.lastVisibleActionCreated change (line 121-123), i.e. exactly when a message arrives.
• Skip branch: useMarkAsRead.ts:117 sets readActionSkippedRef.current = true.
• Deferred completion tied to the unread marker scrolling into view: completeSkippedMarkAsRead → wired via onUnreadActionVisible.
• LHN bold decision: isUnread (lastReadTime < lastVisibleActionCreated), surfaced via SidebarUtils.ts:923 and shouldUseBoldText.
• Comparison for the older, un-gated copy: MoneyRequestReportActionsList.tsx:355-364.

Confidence: medium. The mechanism and skip path are certain from the code; the exact failing gate at line 106 (leaning toward !hasNewerActions) should be confirmed with a client-side repro that logs hasNewerActions, isScrolledToEnd, isVisible, and Visibility.hasFocus() at the moment the inbound message lands.

Possibly related open issues: #92673 (unread marker not displayed on a new conversation) and #94794 (new message marker when marking own message unread) touch the same unread/marker area.

---

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

[kitvasyl]

Proposal

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

A message received while its conversation is open is visible to the user, but after navigating away the conversation appears bold in the LHN and retains a new-message marker.

What is the root cause of that problem?

src/pages/inbox/ReportLifecycleHandler.tsx handles the active report lifecycle, but its focus logic only calls clearReportNotifications(). When an incoming action updates the open report, nothing in this component advances lastReadTime, so lastVisibleActionCreated can become newer than lastReadTime. The report is then classified as unread after navigation.

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

In ReportLifecycleHandler, subscribe to the report's lastVisibleActionCreated and call readNewestAction() from src/libs/actions/Report/index.ts whenever that value changes while the report is focused and topmost. Pass the unloaded state conservatively so readNewestAction() uses its existing cached-report-actions guard before issuing the write. This keeps lastReadTime synchronized with messages actually displayed in the active conversation.

Add a regression test covering an incoming message while the report is focused, followed by navigation away, and verify the report is no longer unread.

What alternative solutions did you explore? (Optional)

Marking the report as read only when navigating away would be more vulnerable to a race with incoming action updates. Updating it when the visible action changes directly represents when the message was displayed.

[aswin-s]

Proposal

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

When a user is viewing a 1:1 chat and the other user sends a new message, then the current user navigates away from the conversation, the chat is shown bold (unread) in the LHN with a "New message" marker — even though the message was seen while the chat was focused. Expected: since the message was received while the chat was open, it should be marked read and the LHN entry should not be bold.

What is the root cause of that problem?

In src/hooks/useMarkAsRead.ts:83-91, the initial mark-as-read effect sets didMarkReportAsReadInitially.current = true unconditionally on its first run and then early-returns on every subsequent run, so once the chat opens with no unread state the guard latches shut. When a new inbound message arrives while the chat is focused, isReportUnreadValue (line 64, driven by isUnread at src/libs/ReportUtils.ts:8998 plus isCurrentActionUnread) flips to true, but the guard prevents readNewestAction from firing. The sibling report-change effect at line 121 only depends on report?.lastVisibleActionCreated, transactionThreadReport?.lastVisibleActionCreated, reportID, isVisible, isReportActionsLoaded — not on lastAction/sortedVisibleReportActions — so it also misses the inbound. On navigate-away, nothing has marked the report read, and LHN renders it bold.

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

1. src/hooks/useMarkAsRead.ts:83-91 — remove or narrow the didMarkReportAsReadInitially latch so the effect re-fires when isReportUnreadValue transitions from false → true while focused (e.g., only skip if the report was already unread on mount, not for the lifetime of the hook).
2. src/hooks/useMarkAsRead.ts:121-123 — add lastAction?.reportActionID (or sortedVisibleReportActions.at(0)?.reportActionID) to the effect deps so handleReportChangeMarkAsRead re-evaluates when a new inbound action arrives while focused, matching the intent of line 64's isCurrentActionUnread check.
3. Add a unit/integration test in tests/unit/ covering: user in 1:1 chat, focused/visible, receives an inbound action → readNewestAction fires, LHN isUnread returns false after navigate-away.

What alternative solutions did you explore? (Optional)

[ahmdshrif]

Proposal

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

After opening a conversation and reading it, the conversation is incorrectly re-flagged as unread in the LHN once the user navigates away from it. The report should stay read.

What is the root cause of that problem?

When a report is opened, useMarkAsRead decides whether to commit the read immediately or to defer it. In handleReportChangeMarkAsRead, the read is only performed when shouldReadOnReportChange is true, which additionally requires !hasNewerActions && isScrolledToEnd:

App/src/hooks/useMarkAsRead.ts

Lines 106 to 117 in acfa48f

	const shouldReadOnReportChange = ((isVisible && Visibility.hasFocus()) || isFromNotification) && !hasNewerActions && isScrolledToEnd;
	if (shouldReadOnReportChange) {
	readNewestAction(reportID, isReportActionsLoaded);
	if (isFromNotification) {
	Navigation.setParams({referrer: undefined});
	}
	didMarkOnReportChangeRef.current = true;
	return;
	}
	readActionSkippedRef.current = true;

If that gate is false, it does NOT advance lastReadTime — it only records the intent by setting readActionSkippedRef.current = true. That deferred read is committed solely by completeSkippedMarkAsRead, which no-ops unless Visibility.hasFocus() is true:

App/src/hooks/useMarkAsRead.ts

Lines 171 to 177 in acfa48f

	const completeSkippedMarkAsRead = () => {
	if (!readActionSkippedRef.current || !Visibility.hasFocus()) {
	return;
	}
	markNewestActionAsRead();
	};

So when the user navigates away before the skip is completed, the report's lastReadTime is never updated. The in-chat marker looked cleared, but SidebarUtils still computes lastReadTime < lastVisibleActionCreated, so the LHN renders it as unread.

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

Flush the pending skipped read when leaving the report instead of dropping it. Complete the skipped read on report change / blur regardless of current focus, e.g. in handleReportChangeMarkAsRead (or an unmount/blur effect) call the read before the report instance is reused:

// when leaving a report that had a skipped read, commit it
if (readActionSkippedRef.current) {
    readNewestAction(reportID, isReportActionsLoaded);
    readActionSkippedRef.current = false;
}

Regression risk: ensure this does not mark genuinely-unread reports (ones the user never scrolled/read) as read — only flush when a read was actually skipped for this reportID.

[Abdulloh0109]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 06:00:28 UTC.

Proposal

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

A 1:1 chat stays bold/unread in the LHN (with a "New message" marker) after receiving a message while the chat is open and then navigating away, even though the message was effectively seen. This happens when the message arrives while the window/app is momentarily unfocused, and focus is later regained without a document-visibility change.

What is the root cause of that problem?

The LHN "unread/bold" state is driven purely by isUnread, i.e. lastReadTime < lastVisibleActionCreated:

App/src/libs/ReportUtils.ts

Line 8906 in acfa48f

const isUnreadFromTimestamp = lastReadTime < (lastVisibleActionCreated ?? '') || lastReadTime < lastMentionedTime;

So the chat is bold because readNewestAction never runs for the incoming message, leaving lastReadTime behind the new action. In useMarkAsRead, marking a report read on an incoming message is gated on the window having OS focus (Visibility.hasFocus()), and every path that can complete a deferred read is missing when focus returns without a visibility change:

1. Immediate read on a new action requires Visibility.hasFocus(). If the window is unfocused when the message lands, the read is skipped and only a flag is set:
   

   App/src/hooks/useMarkAsRead.ts

   Line 106 in acfa48f

   const shouldReadOnReportChange = ((isVisible && Visibility.hasFocus()) || isFromNotification) && !hasNewerActions && isScrolledToEnd;

   
   

   App/src/hooks/useMarkAsRead.ts

   Line 117 in acfa48f

   readActionSkippedRef.current = true;

2. The visibility/focus catch-up (handleAppVisibilityMarkAsRead) also requires Visibility.hasFocus(), and it only re-runs when isVisible or isFocused change:
   

   App/src/hooks/useMarkAsRead.ts

   Lines 125 to 159 in acfa48f

   	const handleAppVisibilityMarkAsRead = useEffectEvent(() => {
   	if (didMarkOnReportChangeRef.current) {
   	didMarkOnReportChangeRef.current = false;
   	return;
   	}
   	if (reportID !== prevReportID) {
   	return;
   	}
   	if (!isVisible || !Visibility.hasFocus() || !isFocused) {
   	if (!lastMessageTime.current) {
   	lastMessageTime.current = lastAction?.created ?? '';
   	}
   	return;
   	}
   	const newMessageTimeReference = lastMessageTime.current && report?.lastReadTime && lastMessageTime.current > report.lastReadTime ? userActiveSince.current : report?.lastReadTime;
   	lastMessageTime.current = null;
   	const isArchivedReport = isArchivedNonExpenseReport(report, isReportArchived);
   	const hasNewMessagesInView = isScrolledToEnd;
   	const hasUnreadReportAction = sortedVisibleReportActions.some(
   	(reportAction) =>
   	newMessageTimeReference &&
   	newMessageTimeReference < reportAction.created &&
   	(isReportPreviewAction(reportAction) ? reportAction.childLastActorAccountID : reportAction.actorAccountID) !== currentUserAccountID,
   	);
   	if (!isArchivedReport && (!hasNewMessagesInView || !hasUnreadReportAction)) {
   	return;
   	}
   	readNewestAction(reportID, true);
   	userActiveSince.current = DateUtils.getDBTime();
   	});

   
   

   App/src/hooks/useMarkAsRead.ts

   Lines 162 to 164 in acfa48f

   	useEffect(() => {
   	handleAppVisibilityMarkAsRead();
   	}, [isVisible, isFocused]);

3. But isVisible only tracks document visibility (Visibility.onVisibilityChange), and isFocused is the React Navigation screen focus. Neither changes when a still-visible window merely regains OS focus (e.g. clicking back to the Expensify tab/window on macOS Chrome, or the app returning to active on iOS). So this effect never re-fires on focus return:
   

   App/src/hooks/useMarkAsRead.ts

   Lines 50 to 56 in acfa48f

   	const [isVisible, setIsVisible] = useState(Visibility.isVisible);
   	useEffect(() => {
   	const unsubscribe = Visibility.onVisibilityChange(() => {
   	setIsVisible(Visibility.isVisible());
   	});
   	return unsubscribe;
   	}, []);

4. The other completion path, completeSkippedMarkAsRead (fired from onUnreadActionVisible on a viewability change), also requires Visibility.hasFocus() and is only triggered by a scroll/viewability change — not by focus return:
   

   App/src/hooks/useMarkAsRead.ts

   Lines 171 to 176 in acfa48f

   	const completeSkippedMarkAsRead = () => {
   	if (!readActionSkippedRef.current || !Visibility.hasFocus()) {
   	return;
   	}
   	markNewestActionAsRead();
   	};

   
   

   App/src/pages/inbox/report/useReportUnreadMessageScrollTracking.ts

   Lines 135 to 137 in acfa48f

   	if (hasUnreadMarkerReportAction && unreadActionVisible) {
   	ref.current.onUnreadActionVisible();
   	}

Net result: the deferred read is stranded. lastReadTime stays behind lastVisibleActionCreated, so after navigating away the chat is bold and keeps the "New message" marker.

This is a regression. The exact catch-up for this scenario existed and was removed inside PR #93387:

• Added in 23ce2314c1b ("fix: handle focus-based read catch-up") with the comment "A visible browser window can regain OS focus without a visibility change, so rerun the read catch-up on app focus too.":
  23ce231
• Removed in 5ce49698add ("fix: remove unnecessary focus catch-up"), deleting useAppFocusEvent(markAsReadWhenVisibleAndFocused):
  5ce4969

useAppFocusEvent is precisely the OS-focus signal that isVisible/isFocused do not cover — web listens to window focus, native to AppState active:

App/src/hooks/useAppFocusEvent/index.ts

Lines 10 to 16 in acfa48f

	useEffect(() => {
	window.addEventListener('focus', callback);
	return () => {
	window.removeEventListener('focus', callback);
	};
	}, [callback]);

App/src/hooks/useAppFocusEvent/index.native.ts

Lines 6 to 13 in acfa48f

	useEffect(() => {
	const subscription = AppState.addEventListener('change', (appState) => {
	if (appState !== 'active') {
	return;
	}
	callback();
	});

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

[melvin-bot]

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

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-02 05:53:30 UTC.

Proposal

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

When you're sitting in a 1:1 chat and the other person sends a message, that message should be marked as read since you're already looking at it. Instead, after you navigate away, the chat shows up bold (unread) in the LHN with a "New message" marker, even though you saw the message.

What is the root cause of that problem?

The mark-as-read gate in useMarkAsRead decides whether an incoming message should be read based on isScrolledToEnd, but that value can be false even when you're genuinely parked at the bottom of the chat.

In ReportActionsList.tsx, isScrolledToEnd is passed as !hasScrolledOverThreshold (line 188). hasScrolledOverThreshold is a useState initialized from scrollOffsetRef.current >= ACTION_VISIBLE_THRESHOLD (line 172) and only ever updated inside the manual onScroll handler (line 280). Nothing resets it back to false after a programmatic scroll-to-bottom or autoscroll. So when a new message lands while you're at the bottom and no settling scroll event fires, that state stays stale-true, which makes isScrolledToEnd wrongly false.

That flows straight into the gate at useMarkAsRead.ts:106:

const shouldReadOnReportChange = ((isVisible && Visibility.hasFocus()) || isFromNotification) && !hasNewerActions && isScrolledToEnd;

With isScrolledToEnd false the branch is skipped and only readActionSkippedRef.current = true is set. That skip is designed to be completed later by completeSkippedMarkAsRead, but that only fires on a viewability "enter" transition. An action that's already visible at the bottom never re-enters the viewport, so the skip is never resolved. Then you navigate away, isFocused goes false, handleAppVisibilityMarkAsRead early-returns, and the report is left unread.

This is a regression from PR #73651 (commit f1320a4884a, 2026-06-02). Before that refactor, the check read the live offset at the moment of marking (scrollOffsetRef.current < ACTION_VISIBLE_THRESHOLD); the refactor replaced that live read with the lagging hasScrolledOverThreshold state. The same PR also added Visibility.hasFocus() to the gate, which was intentional and should stay.

While tracing this I noticed a second inconsistency in the same hook: readNewestAction is called with the possibly-false isReportActionsLoaded at lines 90 and 109, but with a hardcoded true at lines 157 and 168. When actions aren't loaded yet, passing false there can make the read silently no-op, which widens the window for this bug.

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

Restore the live-offset read that existed before #73651. Pass scrollOffsetRef into useMarkAsRead and compute the value at mark time inside handleReportChangeMarkAsRead:

const isScrolledToEnd = scrollOffsetRef.current < CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD;

Reading the ref at the moment we decide to mark as read avoids the stale-state problem entirely, since the ref always holds the current offset. This is the minimal, behavior-preserving restoration and doesn't touch the intentional Visibility.hasFocus() guard.

I'd also make the isReportActionsLoaded argument to readNewestAction consistent across the four call sites so a not-yet-loaded state can't silently drop the read.

The area has a test gap worth closing too. tests/unit/useMarkAsReadTest.ts feeds isScrolledToEnd as a fixed prop, so it never exercises the ReportActionsList path where that boolean is derived from stale scroll state. I'll add a case: a message arrives while at the bottom with a stale threshold flag, and the report should still be marked read.

What alternative solutions did you explore? (Optional)

Resetting hasScrolledOverThreshold to false after every programmatic scroll-to-bottom/autoscroll would also work, but it means chasing down each scroll path and keeps the read decision dependent on a re-render landing before the mark happens. Reading the ref directly is smaller and doesn't have that timing dependency. I also considered completing the skipped read on navigate-away, but that patches the symptom downstream rather than fixing the wrong signal at the source.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022072555997276765693