[$250] Messages not highlighted as unread in LHN on web / real-time message updates not reflected

[mountiny]

Problem

New messages in NewDot on web are sometimes not highlighted as unread in the LHN (Left Hand Navigation), causing users to silently miss incoming messages. Additionally, the LHN preview may show stale content — different from the latest message in the conversation — and the actual message only appears after navigating away from and back into the conversation.

Reported on Staging web v9.3.70-3. Multiple users have independently confirmed the behavior.

Current Behavior

• A new message arrives in a conversation but the conversation is not marked as unread in the LHN
• The user only discovers the new message by manually opening the conversation
• The LHN row preview does not update to reflect the latest message in real time
• The correct message eventually appears after navigating out of and back into the conversation

Expected Behavior

• New messages mark the conversation as unread in the LHN
• The LHN row preview updates in real time to show the latest message
• Users receive the appropriate unread badge/highlight so they are aware of new activity

Platforms Confirmed

• Web (Staging v9.3.70-3)

Reproduction Steps

No reliable steps to reproduce yet. The issue occurs intermittently — more often than not messages do appear as unread, but users have reported it failing across multiple separate conversations.

Notes

• Slack thread with reports: https://expensify.slack.com/archives/C05LX9D6E07/p1778593328736269
• Related reports from carlos: https://expensify.slack.com/archives/C049HHMV9SM/p1778602314138499

Who Can Help Reproduce?

If you experience this, please share:

1. Platform and app version
2. Whether you are the sender or receiver of the message
3. Approximate time the message was sent
4. Whether the LHN preview was also stale or only the unread state was wrong
5. Any actions taken immediately before the missed unread (e.g. switching tabs, navigating away)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054473075617053165
• Upwork Job ID: 2054473075617053165
• Last Price Increase: 2026-06-24

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Proposal

What is the root cause of that problem?

There are likely multiple contributing factors that combine to cause the intermittent failure. The investigation identified three mechanisms that can each independently suppress the unread indicator or stale the LHN preview:

1. Race condition: auto-read fires on the same render cycle as the incoming message

When the user has a report open and scrolled to the bottom, handleReportChangeMarkAsRead has report.lastVisibleActionCreated in its dependency array. When a Pusher update arrives with a new lastVisibleActionCreated, the callback is recreated and immediately executed by the effect at line 618. If the user is visible + scrolled to end, it calls readNewestAction() which optimistically sets lastReadTime = getDBTimeWithSkew() — a value guaranteed to be ≥ lastVisibleActionCreated. The LHN never gets a render where isUnread() returns true.

This explains why messages in the currently viewed report can appear without an unread indicator or LHN preview update — the report is marked as read before the LHN row re-renders.

2. Derived Onyx value timing gap

DERIVED.VISIBLE_REPORT_ACTIONS must recompute before OptionRowLHNData can resolve the correct lastAction. If REPORT_ACTIONS subscriber fires before the derived value has recomputed, the lastAction useMemo resolves to the old last visible action, producing stale preview text in the LHN. The correct text only appears after navigating away and back (forcing a full re-render with settled data).

3. OnyxUpdateManager gap detection deferral

When applyOnyxUpdatesReliably detects a gap in updateIDs (previousUpdateID doesn't match client's last known), it defers the update and fetches missing updates first. During this deferral window, neither the unread state nor the preview text updates. Multi-tab scenarios compound this because both User.ts and OnyxUpdateManager check isClientTheLeader() — if leader election is flaky, updates could be silently dropped.

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

For cause #1: Add a short debounce or requestAnimationFrame yield in the effect at ReportActionsList.tsx:618-630 so that the auto-read doesn't fire in the same render batch as the Onyx update. This gives the LHN at least one render cycle to show the unread indicator before it's cleared by auto-read.

For cause #2: Ensure OptionRowLHNData subscribes to DERIVED.VISIBLE_REPORT_ACTIONS as a dependency of lastAction in a way that triggers a re-render when the derived value settles. If the current useOnyx + deepEqual selector comparison is swallowing the update, the selector at OptionRowLHNData.tsx:59-79 may need to return a new reference when the content changes.

For cause #3: This requires deeper investigation into OnyxUpdateManager gap handling and leader election reliability. Consider adding telemetry around gap detection events and leader status changes.

What alternative solutions did you explore? (Optional)

• Server-side push of lastReadTime: Having the server enforce that lastReadTime is never set ahead of the most recent action's created time. Rejected because it would require API changes and doesn't address the LHN preview staleness.
• Removing the lastActorAccountID guard at SidebarUtils.ts:870 — the && !!report.lastActorAccountID check silently suppresses unread if the Pusher payload omits this field. However, the comment explains it's there to avoid false-positive bold on empty chats, so removing it would reintroduce that regression.

Investigation details

Data flow for unread indicators:

1. Pusher sends multipleEvents → User.ts:919 receives and calls applyOnyxUpdatesReliably()
2. If no update gap: Onyx.update() merges report fields (lastVisibleActionCreated, lastActorAccountID, lastMessageText) and report actions
3. Onyx subscribers fire → OptionRowLHNData re-renders → SidebarUtils.getOptionData() calls isUnread(report)
4. isUnread() at ReportUtils.ts:8999 returns lastReadTime < lastVisibleActionCreated
5. Simultaneously: If report is currently focused, handleReportChangeMarkAsRead fires due to lastVisibleActionCreated dependency change → readNewestAction() optimistically sets lastReadTime = getDBTimeWithSkew() → isUnread() returns false

Additional risk factor — getDBTimeWithSkew asymmetry:
NetworkState.ts:216-222 only applies positive skew correction. If the client clock runs ahead of the server (negative skew), lastReadTime can be set to a future timestamp relative to the server, potentially marking even subsequently arriving messages as already read.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-18 16:57:42 UTC.

Proposal

What is the root cause of that problem?

The LHN unread highlight, the Unread/To-do tab membership and badge counts, and the LHN sort order are all driven by an incremental cache in useSidebarOrderedReports, and that cache silently drops report updates whenever Onyx broadcasts coalesce into a single React render. The per-row preview/bold is re-derived from fresh chatReports on every render, so this is specifically why a new message doesn't bubble the conversation to the top and doesn't show up as unread in the LHN, while opening the conversation fixes it.

1. The hook only re-evaluates the reports named in sourceValue.
The provider subscribes to the report collection and keeps only the latest delta:

App/src/hooks/useSidebarOrderedReports.tsx

Line 92 in d81cc58

const [chatReports, {sourceValue: reportUpdates}] = useOnyx(ONYXKEYS.COLLECTION.REPORT);

getUpdatedReports() then builds the set of reports to recompute almost entirely from that reportUpdates delta:

App/src/hooks/useSidebarOrderedReports.tsx

Lines 132 to 136 in d81cc58

	if (reportUpdates) {
	for (const key of Object.keys(reportUpdates ?? {})) {
	reportsToUpdate.add(key);
	}
	}

That set is the only thing the incremental path touches — updateReportsToDisplayInLHN iterates exclusively over updatedReportsKeys and copies a report into the displayed set only if it appears there:

App/src/hooks/useSidebarOrderedReports.tsx

Lines 200 to 226 in d81cc58

	const reportsToDisplayInLHN = useMemo(() => {
	const updatedReports = getUpdatedReports();
	const hasCachedReports = Object.keys(currentReportsToDisplay).length > 0;
	// When reportAttributes changes (e.g. on startup hydration) but no report-specific keys were
	// updated, getUpdatedReports() returns []. Rather than falling through to a full scan of all
	// reports, recheck only the already-displayed reports with the new reportAttributes.
	const effectiveUpdatedReports = updatedReports.length === 0 && hasCachedReports ? Object.keys(currentReportsToDisplay) : updatedReports;
	const shouldDoIncrementalUpdate = effectiveUpdatedReports.length > 0 && hasCachedReports;
	let reportsToDisplay = {};
	if (shouldDoIncrementalUpdate) {
	reportsToDisplay = SidebarUtils.updateReportsToDisplayInLHN({
	displayedReports: currentReportsToDisplay,
	reports: chatReports,
	updatedReportsKeys: effectiveUpdatedReports,
	currentReportId: derivedCurrentReportID,
	isInFocusMode: priorityMode === CONST.PRIORITY_MODE.GSD,
	betas,
	transactionViolations,
	reportNameValuePairs,
	reportAttributes,
	draftComments: reportsDrafts,
	transactions,
	isOffline,
	currentUserLogin: currentUserLogin ?? '',
	currentUserAccountID: accountID,
	});

App/src/libs/SidebarUtils.ts

Lines 472 to 524 in d81cc58

	for (const reportID of updatedReportsKeys) {
	const report = reports?.[reportID];
	if (!report) {
	if (reportID in displayedReports) {
	delete getMutableCopy()[reportID];
	}
	continue;
	}
	// Get the specific draft comment for this report instead of using a single draft comment for all reports
	// This fixes the issue where the current report's draft comment was incorrectly used to filter all reports
	const reportDraftComment = draftComments?.[`${ONYXKEYS.COLLECTION.REPORT_DRAFT_COMMENT}${report.reportID}`];
	const isReportArchived = isArchivedReport(reportNameValuePairs?.[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${report.reportID}`] ?? {});
	const {shouldDisplay, hasErrorsOtherThanFailedReceipt} = shouldDisplayReportInLHN({
	report,
	reports,
	currentReportId,
	isInFocusMode,
	betas,
	transactionViolations,
	draftComment: reportDraftComment,
	transactions,
	isOffline,
	isReportArchived,
	reportAttributes,
	currentUserLogin,
	currentUserAccountID,
	});
	if (shouldDisplay) {
	const requiresAttention = reportAttributes?.[report?.reportID]?.requiresAttention ?? false;
	const isUnreadReport = getIsUnreadReportForInboxTab(report, isReportArchived);
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const hasFlags = requiresAttention || hasErrorsOtherThanFailedReceipt || isUnreadReport;
	const existingEntry = displayedReports[reportID];
	if (hasFlags) {
	if (
	existingEntry !== report ||
	existingEntry?.requiresAttention !== requiresAttention ||
	existingEntry?.hasErrorsOtherThanFailedReceipt !== hasErrorsOtherThanFailedReceipt ||
	existingEntry?.isUnreadReport !== isUnreadReport
	) {
	getMutableCopy()[reportID] = {...report, requiresAttention, hasErrorsOtherThanFailedReceipt, isUnreadReport};
	}
	} else if (existingEntry !== report) {
	getMutableCopy()[reportID] = report;
	}
	} else if (reportID in displayedReports) {
	delete getMutableCopy()[reportID];
	}
	}

2. sourceValue is overwritten on every broadcast, so coalesced updates lose all but the last delta.
In react-native-onyx, the collection subscriber stores the delta in a single ref that is overwritten on each callback (useOnyx.js → sourceValueRef.current = sourceValue), and the value read by the hook is whatever was last written. useOnyx is a useSyncExternalStore subscription: when several report broadcasts fire before React commits a render (rapid Pusher events, or multiple Onyx.merge calls across separate broadcasts), React coalesces them into one render, but sourceValueRef has already been overwritten down to the last delta. So reportUpdates reports {report_B} while chatReports already contains the merged data for both report_A and report_B. report_A is never added to updatedReportsKeys, so the incremental update never re-evaluates it.

3. The stale cache, not stale report data, is what the user sees.
Because the dropped report is never recomputed, its cached entry keeps the old lastVisibleActionCreated and the old isUnreadReport flag. That cache is what feeds:

• sort order — the comparator sorts by the cached lastVisibleActionCreated taken from the displayed set, so the conversation does not move to the top:

  App/src/libs/SidebarUtils.ts

  Lines 545 to 557 in d81cc58

  	for (const report of Object.values(reportsToDisplay)) {
  	if (!report) {
  	continue;
  	}
  	const reportID = report.reportID;
  	const displayName = getReportNameFromDerived(report, reportAttributes);
  	const miniReport: MiniReport = {
  	reportID,
  	displayName,
  	sortKey: buildSortKey(displayName),
  	lastVisibleActionCreated: report.lastVisibleActionCreated,
  	};

  and

  App/src/libs/SidebarUtils.ts

  Lines 628 to 630 in d81cc58

  	const compareDatesDesc = (a: MiniReport, b: MiniReport) =>
  	a?.lastVisibleActionCreated && b?.lastVisibleActionCreated ? compareStringDates(b.lastVisibleActionCreated, a.lastVisibleActionCreated) : 0;

• Unread/To-do tab membership and the tab badge counts — both read the cached isUnreadReport:

  App/src/libs/SidebarUtils.ts

  Lines 1535 to 1571 in d81cc58

  	function filterReportsForInboxTab(reportIDs: string[], reportsToDisplay: ReportsToDisplayInLHN, activeTab: ValueOf<typeof CONST.INBOX_TAB>): string[] {
  	if (activeTab === CONST.INBOX_TAB.ALL) {
  	return reportIDs;
  	}
  	return reportIDs.filter((reportID) => {
  	const report = reportsToDisplay[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
  	if (!report) {
  	return false;
  	}
  	switch (activeTab) {
  	case CONST.INBOX_TAB.TODO:
  	return getIsTodoReportForInboxTab(report);
  	case CONST.INBOX_TAB.UNREAD:
  	return !!report.isUnreadReport;
  	default:
  	return true;
  	}
  	});
  	}
  	/** Counts how many of the ordered reports fall into the To-do and Unread Inbox tabs, for the count badge shown on each. */
  	function getInboxTabCounts(reportIDs: string[], reportsToDisplay: ReportsToDisplayInLHN): Record<typeof CONST.INBOX_TAB.TODO | typeof CONST.INBOX_TAB.UNREAD, number> {
  	let todoCount = 0;
  	let unreadCount = 0;
  	for (const reportID of reportIDs) {
  	const report = reportsToDisplay[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
  	if (!report) {
  	continue;
  	}
  	if (getIsTodoReportForInboxTab(report)) {
  	todoCount++;
  	}
  	if (report.isUnreadReport) {
  	unreadCount++;

4. Why opening the conversation fixes it (and why this isn't an Onyx-pipeline stall).
When the user navigates into the report, getUpdatedReports() force-adds the previous and current report IDs to the recompute set:

App/src/hooks/useSidebarOrderedReports.tsx

Lines 174 to 178 in d81cc58

	// Make sure the previous and current reports are always included in the updates when we switch reports.
	if (prevDerivedCurrentReportID !== derivedCurrentReportID) {
	reportsToUpdate.add(`${ONYXKEYS.COLLECTION.REPORT}${prevDerivedCurrentReportID}`);
	reportsToUpdate.add(`${ONYXKEYS.COLLECTION.REPORT}${derivedCurrentReportID}`);
	}

That forces the stranded report through updateReportsToDisplayInLHN, which finally refreshes its cached lastVisibleActionCreated and isUnreadReport from the (already-correct) chatReports data — so it re-sorts to the top and re-appears in the Unread tab. This is exactly the reported "appears only after navigating out of and back into the conversation," and it proves the underlying Onyx data was already correct — the defect is the LHN incremental cache, not a Pusher/Onyx write that never landed.

So: rapid report broadcasts coalesce into one render → sourceValue keeps only the last delta → getUpdatedReports() omits the other updated reports → updateReportsToDisplayInLHN never refreshes their cached lastVisibleActionCreated/isUnreadReport → conversation doesn't rise to the top, isn't flagged unread, and isn't counted in the Unread tab → forcing the report into the recompute set on navigation reconciles it. Intermittent by nature, because it depends entirely on broadcast/render timing.

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

Stop treating the single sourceValue delta as the complete set of changed reports. The reliable signal of "which reports changed" is already in scope: chatReports itself — Onyx hands back a fresh object reference for every merged collection member, so a per-key reference diff against the previous collection catches every changed (or newly added/removed) report regardless of how broadcasts coalesce.

Reuse the usePrevious hook that is already imported and already used in this provider for betas/priorityMode/isOffline:

App/src/hooks/useSidebarOrderedReports.tsx

Line 18 in d81cc58

import usePrevious from './usePrevious';

App/src/hooks/useSidebarOrderedReports.tsx

Lines 112 to 114 in d81cc58

	const prevBetas = usePrevious(betas);
	const prevPriorityMode = usePrevious(priorityMode);
	const prevIsOffline = usePrevious(isOffline);

Add const prevChatReports = usePrevious(chatReports); and, inside getUpdatedReports(), fold in every key whose reference changed:

// authoritative changed-report detection, independent of sourceValue coalescing
if (chatReports !== prevChatReports) {
    for (const key of Object.keys(chatReports ?? {})) {
        if (chatReports?.[key] !== prevChatReports?.[key]) {
            reportsToUpdate.add(key);
        }
    }
}

This subsumes the fragile reportUpdates branch (lines 132-136) and is no more expensive than work the hook already does — the existing betas/priorityMode/isOffline branch already iterates every key of chatReports (

App/src/hooks/useSidebarOrderedReports.tsx

Lines 127 to 131 in d81cc58

	if (betas !== prevBetas || priorityMode !== prevPriorityMode || isOffline !== prevIsOffline) {
	for (const key of Object.keys(chatReports ?? {})) {
	reportsToUpdate.add(key);
	}
	}

), and the loop only runs when chatReports's identity changed, i.e. only when there actually was an update. The incremental fast-path is preserved (we still recompute only the reports that changed); we just compute that set from a source of truth that can't silently drop entries. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Accumulate sourceValue deltas across renders into a ref of "pending" report IDs and clear it only once they have been flushed into currentReportsToDisplay (the displayed set is committed asynchronously via the effect at

App/src/hooks/useSidebarOrderedReports.tsx

Lines 285 to 287 in d81cc58

	useEffect(() => {
	setCurrentReportsToDisplay(reportsToDisplayInLHN);
	}, [reportsToDisplayInLHN]);

, which adds a second, separate window where deltas can be lost). This works but adds mutable cross-render bookkeeping and still depends on sourceValue ever observing each delta. The reference-diff against prevChatReports is simpler, has no hidden state, and is correct by construction because it reads the same chatReports the rest of the hook already consumes.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

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

When a new message arrives in a conversation on web while the user has that conversation open and scrolled to the bottom, the conversation is not marked as unread in the LHN and the preview does not update to reflect the new message. The user only discovers the incoming message by navigating away from and back into the conversation. This occurs because the auto-read mechanism fires synchronously in the same render cycle as the incoming Pusher update, preventing the LHN from ever rendering a state where the conversation appears unread.

What is the root cause of that problem?

The bug originates in handleReportChangeMarkAsRead in src/pages/inbox/report/ReportActionsList.tsx (lines 547–572). This callback is wrapped in useCallback with report.lastVisibleActionCreated as a dependency. When Pusher delivers a new report action for the currently focused report, lastVisibleActionCreated changes, the callback is rebuilt, and the unified useEffect at lines 618–630 immediately invokes it — all within the same React render batch. If the user is visible, scrolled to the bottom, and has no newer actions to load, readNewestAction is called, which optimistically writes lastReadTime = getDBTimeWithSkew() — a timestamp guaranteed to be ≥ the newly arrived action's timestamp. Because this write occurs in the same commit phase as the Onyx update that brought the new message, the LHN row never gets a render where isUnread(report) (which compares lastReadTime < lastVisibleActionCreated) returns true, so the unread bold and preview update are suppressed.

App/src/pages/inbox/report/ReportActionsList.tsx

Lines 547 to 575 in a444e78

	const handleReportChangeMarkAsRead = useCallback(() => {
	if (report.reportID !== prevReportID) {
	return;
	}
	const isLastActionUnread = lastAction && isCurrentActionUnread(report, lastAction, sortedVisibleReportActions);
	if (!isUnread(report, transactionThreadReport, isReportArchived) && !isLastActionUnread) {
	return;
	}
	// On desktop, when the notification center is displayed, isVisible will return false.
	// Currently, there's no programmatic way to dismiss the notification center panel.
	// To handle this, we use the 'referrer' parameter to check if the current navigation is triggered from a notification.
	const isFromNotification = route?.params?.referrer === CONST.REFERRER.NOTIFICATION;
	const isScrolledToEnd = scrollOffsetRef.current < CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD;
	if ((isVisible || isFromNotification) && !hasNewerActions && isScrolledToEnd) {
	readNewestAction(report.reportID, !!reportLoadingState?.hasOnceLoadedReportActions);
	if (isFromNotification) {
	Navigation.setParams({referrer: undefined});
	}
	return true;
	}
	readActionSkipped.current = true;
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [report.lastVisibleActionCreated, transactionThreadReport?.lastVisibleActionCreated, report.reportID, isVisible, reportLoadingState?.hasOnceLoadedReportActions]);
	const handleAppVisibilityMarkAsRead = useCallback(() => {
	if (report.reportID !== prevReportID) {

The working analog handleAppVisibilityMarkAsRead avoids this issue because its dependency array ([isFocused, isVisible, reportLoadingState?.hasOnceLoadedReportActions]) does not include lastVisibleActionCreated, so it does not re-run synchronously when a new message arrives via Pusher. Its logic also contains an early-exit guard that requires a detectable gap between lastMessageTime and report.lastReadTime, giving the LHN at least one render cycle to observe the unread state.

App/src/pages/inbox/report/ReportActionsList.tsx

Lines 476 to 513 in a444e78

	});
	useEffect(() => () => clearTimeout(scrollEndTimerRef.current), []);
	useScrollToEndOnNewMessageReceived({
	sizeChangeType: 'changed',
	scrollOffsetRef,
	lastActionID: lastAction?.reportActionID,
	visibleActionsLength: sortedVisibleReportActions.length,
	hasNewestReportAction,
	setIsFloatingMessageCounterVisible,
	scrollToEnd: reportScrollManager.scrollToBottom,
	// Include reportID so list-length / last-id baselines reset when the same screen instance shows another report.
	resetKey: `${report.reportID}:${linkedReportActionID}`,
	});
	useEffect(() => {
	if (!draftAutoScrollKey || previousDraftAutoScrollKey === draftAutoScrollKey) {
	return;
	}
	if (scrollOffsetRef.current >= AUTOSCROLL_TO_TOP_THRESHOLD || !hasNewestReportAction) {
	return;
	}
	setIsFloatingMessageCounterVisible(false);
	requestAnimationFrame(() => {
	reportScrollManager.scrollToBottom();
	});
	}, [draftAutoScrollKey, hasNewestReportAction, previousDraftAutoScrollKey, reportScrollManager, scrollOffsetRef, setIsFloatingMessageCounterVisible]);
	useEffect(() => {
	const shouldTriggerScroll = shouldFocusToTopOnMount && prevHasCreatedActionAdded && !hasCreatedActionAdded;
	if (!shouldTriggerScroll) {
	return;
	}
	requestAnimationFrame(() => reportScrollManager.scrollToEnd());
	}, [hasCreatedActionAdded, prevHasCreatedActionAdded, shouldFocusToTopOnMount, shouldScrollToEndAfterLayout, reportScrollManager]);

The root cause is therefore not the dependency list itself — lastVisibleActionCreated must stay in the deps so the callback correctly detects and responds to new message arrivals — but rather the fact that once the callback fires, readNewestAction executes synchronously within the same render batch, never giving React a chance to flush the intermediate unread state to the LHN.

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

File: src/pages/inbox/report/ReportActionsList.tsx
Function: handleReportChangeMarkAsRead (lines 547–572)

Wrap the readNewestAction call in a setTimeout(0) so it is deferred to a subsequent task, outside the current render batch. This ensures React flushes the intermediate state (new message present, lastReadTime not yet updated) to the LHN before the optimistic write occurs, making isUnread(report) briefly true and triggering the unread highlight and preview update. The report.lastVisibleActionCreated dependency remains in place — the callback still rebuilds and fires whenever a new message arrives, preserving correct detection semantics.

-        if ((isVisible || isFromNotification) && !hasNewerActions && isScrolledToEnd) {
-            readNewestAction(report.reportID, !!reportLoadingState?.hasOnceLoadedReportActions);
-            if (isFromNotification) {
-                Navigation.setParams({referrer: undefined});
-            }
-            return true;
-        }
+        if ((isVisible || isFromNotification) && !hasNewerActions && isScrolledToEnd) {
+            setTimeout(() => {
+                readNewestAction(report.reportID, !!reportLoadingState?.hasOnceLoadedReportActions);
+            }, 0);
+            if (isFromNotification) {
+                Navigation.setParams({referrer: undefined});
+            }
+            return true;
+        }

The return true remains outside the setTimeout so the effect at lines 618–630 still records that a read was scheduled, preventing handleAppVisibilityMarkAsRead from double-firing in the same effect cycle.

Why setTimeout(0) rather than removing the dependency:
Removing lastVisibleActionCreated from the useCallback dep array would leave the callback with a stale closure over the previous lastAction, isUnread, and sortedVisibleReportActions values — none of which are in the dep array (they are intentionally lint-suppressed). With a stale closure the callback would evaluate unread state against the old message list and could silently skip marking a genuinely unread report, or mark as read a report the user has not yet seen. Deferring only the Onyx write sidesteps this entirely: the callback always runs with a fresh closure and current data, and only the optimistic write is pushed to the next task queue entry.

Platform scope:
The deferred write is safe on all platforms. On native, setTimeout(0) resolves after InteractionManager's interaction callbacks and still before the next animation frame, so the observable delay is imperceptible. The existing handleAppVisibilityMarkAsRead already relies on effect-cycle deferral for its correctness, establishing the same pattern. The fix is scoped to the auto-read path for the currently focused report; the initial-open path (useEffect at lines 532–545), manual scroll-to-bottom, and app-visibility resume are unaffected because they do not fire synchronously with Pusher updates.

Onyx hydration safety:
The deferred callback executes after the current render batch commits, at which point Onyx has already written the new report action and lastVisibleActionCreated to the store. readNewestAction therefore reads a fully hydrated snapshot, eliminating any race between the Onyx update and the read-status write.

Blast radius: Scoped to the handleReportChangeMarkAsRead auto-read path. No other callers of readNewestAction are touched.

What alternative solutions did you explore? (Optional)

Removing report.lastVisibleActionCreated from the useCallback dependency array: This was considered because the synchronous firing is mediated by the dep change. However, the callback body references lastAction, isUnread, sortedVisibleReportActions, and transactionThreadReport via closure — none are in the dep array (lint-suppressed). Removing lastVisibleActionCreated would freeze the closure on stale values from before the new message arrived, potentially causing missed or incorrect read-status updates. It also would not prevent the synchronous Onyx write if some other dep change triggered a rebuild. This approach is therefore rejected.

Deferring via InteractionManager.runAfterInteractions: Viable on native but introduces a dependency on a React Native API that behaves differently on web (it resolves immediately via a polyfill). setTimeout(0) is platform-neutral and provides the same one-task-queue deferral on all targets with no behavioral difference in practice.

[aswin-s]

Updated the proposal above to tighten 4 edge cases (additional guards and broader coverage).