[$250] Report does not auto-scroll to new incoming messages when already viewing the report

[melvin-bot]

Bug Description

When a user is actively viewing a report and a new message comes in from another participant, the report does not automatically scroll down to reveal the new message. The user has to manually scroll down to see it.

Note: This is not a deep-linking bug — it is an auto-scroll bug. The report is already open; it simply fails to scroll to the latest message when a new one arrives.

Expected Behavior

When a new message arrives in a report that the user is currently viewing, the report should automatically scroll to the bottom to display the new message.

Actual Behavior

The report stays at its current scroll position. The new message is not shown until the user manually scrolls down.

Steps to Reproduce

1. Open a report with at least one other participant.
2. Have the other participant send a new message.
3. Observe that the report does not scroll down to show the new message.

Platform

• iOS
• Android
• Web
• Desktop

Issue Owner

Current Issue Owner: @aimane-chnaif

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060923318281375991
• Upwork Job ID: 2060923318281375991
• Last Price Increase: 2026-05-31

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two auto-scroll paths in the report view, and neither reliably triggers for a message from another participant:

Path 1 — Pusher live‑tail handler (useReportActionsNewActionLiveTail.ts:78-93) has an explicit early return for non‑self messages — by design it only scrolls when the current user sent the message:

if (!isFromCurrentUser || (!isReportTopmostSplitNavigator() && !Navigation.getReportRHPActiveRoute())) {
    return;
}

So a message from another participant never reaches scrollToBottom() on this path.

Path 2 — fallback hook (useScrollToEndOnNewMessageReceived.ts:62-94) is supposed to cover incoming messages by reacting to the list growing while the user is near the bottom. Its gate:

if (
    scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD &&
    previousLastIndex.current !== lastActionID &&
    didListSizeChange &&
    hasNewestReportAction &&
    prevHasNewestReportAction
) { scrollToEnd(); }
previousLastIndex.current = lastActionID; // ← always advances

Two problems combine to swallow the scroll:

1. hasNewestReportAction (= lastAction.created === report.lastVisibleActionCreated) can transition false → true on the same render the new action lands, because Onyx merges the action and the report.lastVisibleActionCreated field separately. On that render prevHasNewestReportAction is still false, so the gate blocks.
2. previousLastIndex.current = lastActionID runs unconditionally outside the if, so once it advances past the new action's id, the scroll for that message can never re-fire on a subsequent render either — the auto‑scroll is permanently disarmed for that message.

Result: incoming messages from other participants slip through both paths and the view stays put.

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

Make the fallback hook in src/hooks/useScrollToEndOnNewMessageReceived.ts actually reliable for other‑user messages:

1. Drop the prevHasNewestReportAction requirement from the gate. We already check didListSizeChange and hasNewestReportAction for the current render; gating additionally on the previous render's value is what makes a same‑render Onyx flip swallow the scroll.
2. Only advance previousLastIndex.current and reportActionSize.current inside the if (after the scroll fires), not unconditionally on every render. That way a render that misses the gate (e.g. because hasNewestReportAction was briefly false) doesn't permanently disarm the auto‑scroll for that new action — the next render can still catch it.
3. Keep the existing scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD near‑bottom guard — that's what preserves "leave the user where they are if they've scrolled up to read history."

The current‑user‑only guard in useReportActionsNewActionLiveTail can stay as‑is; the fallback hook is the right place for the other‑user case.

What alternative solutions did you explore? (Optional)

Removing the !isFromCurrentUser early return in useReportActionsNewActionLiveTail and instead gating that handler on scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD. This works but duplicates the near‑bottom check that already exists in the fallback hook and entangles the Pusher subscription path with viewport state. Fixing the fallback hook is the smaller, more local change.

Investigation details

Symptoms vs. paths

• Self‑sent message → Path 1 fires → scrolls. ✅
• Other‑user message, user at bottom → Path 1 returns early (guard at line 82); Path 2 should fire but its gate is brittle. ❌
• Other‑user message, user scrolled up reading history → Path 2's near‑bottom guard correctly skips. ✅ (intended)

Why this is "stuck" — the unconditional baseline advance

previousLastIndex.current = lastActionID at line ~81 runs every render, even when the gate didn't pass. So:

• Render N: new action arrives. hasNewestReportAction flips false→true. Gate fails because prevHasNewestReportAction is still false. previousLastIndex.current is set to the new id anyway.
• Render N+1: prevHasNewestReportAction is now true, gate would pass — but previousLastIndex.current !== lastActionID is now false, so it still skips.

The auto‑scroll for that specific message is permanently lost.

Where scroll state lives

scrollOffsetRef is in ActionListContext, created per ReportScreen in useActionListContextValue.ts, and updated on every scroll in ReportActionsList.tsx:437-451. That part is fine — the bug is downstream in how the hook consumes it.

Recent commits in the area (most-likely regression candidates)

• 9d1f19c (2026‑04‑04) "fix: scrolling to bottom on new message sent" — introduced the prevHasNewestReportAction requirement.
• e1e41c3 (2026‑04‑29) — extracted useReportActionsNewActionLiveTail and preserved the current‑user‑only guard.
• 02fa270 (2026‑05‑08) "Reapply: Open reports at first unread action" — reshaped reset behavior of the fallback hook.

Confidence: Medium‑high. The code shape clearly produces the failure mode for incoming messages; the exact Onyx merge ordering that triggers the same‑render flip would be worth confirming during implementation with a quick log on hasNewestReportAction / prevHasNewestReportAction when a Pusher action arrives.

Possibly related open issues

• [$250] Chat is not scrolled to the bottom after creating expense if there is a paid expense in chat #91919 — "Chat is not scrolled to the bottom after creating expense if there is a paid expense in chat" (likely a different code path, but same family of auto-scroll-after-new-action bugs).
• [Due for payment 2026-06-04] [$250] [Performance] Cut ReportActionItem re-renders during message send/receive #91394 — performance work on ReportActionItem re-renders during message send/receive (may touch adjacent code).

---

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-31 03:27:35 UTC.

Replaces my earlier proposal. The earlier draft targeted the new-action subscriber, but active-report incoming messages are not guaranteed to invoke that subscriber. The verified failure is in the shared new-message auto-scroll hook consuming the realtime update before the report metadata and action list are aligned.

Proposal

What is the root cause of that problem?

Incoming messages in an already-open report depend on the shared useScrollToEndOnNewMessageReceived() hook to keep the viewer at the live tail:

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

Lines 474 to 484 in 3ec7273

	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}`,
	});

That hook only scrolls when the latest action ID changes, the list size changes, hasNewestReportAction is true, and the previous render also had hasNewestReportAction true:

App/src/hooks/useScrollToEndOnNewMessageReceived.ts

Lines 62 to 82 in 3ec7273

	useEffect(() => {
	const didListSizeChange = sizeChangeType === 'grewFromReportActions' ? reportActionSize.current > (reportActionsLength ?? 0) : reportActionSize.current !== visibleActionsLength;
	if (
	scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD &&
	previousLastIndex.current !== lastActionID &&
	didListSizeChange &&
	hasNewestReportAction &&
	// We don't want to trigger a scroll to the end if the
	// user was not already close to the end of the chat.
	// When we link to a specific report action and there are
	// no report actions in Onyx, the report action pages might
	// merge, which would cause a scroll to the end otherwise.
	prevHasNewestReportAction
	) {
	setIsFloatingMessageCounterVisible(false);
	scrollToEnd();
	}
	previousLastIndex.current = lastActionID;
	reportActionSize.current = visibleActionsLength;

Realtime Pusher data can update reportActions_* and the report metadata in separate React renders. If the action list updates first, the hook sees the new action while report.lastVisibleActionCreated is still stale, so hasNewestReportAction is false. It then stores the new action ID and length as the baseline. When the report metadata catches up, there is no longer an action/list-size change, so no scroll happens. If the report metadata updates first, the later action-list render fails the prevHasNewestReportAction guard.

The separate new-action subscriber does not reliably cover this active incoming-message path. Notifications are intentionally suppressed when the current report is already topmost and focused:

App/src/libs/actions/Report/index.ts

Lines 4566 to 4570 in 3ec7273

	// If we are currently viewing this report do not show a notification.
	if (reportID === topmostReportID && Visibility.isVisible() && Visibility.hasFocus()) {
	Log.info(`${tag} No notification because it was a comment for the current report`);
	return false;
	}

and the subscriber's scroll path is currently current-user focused:

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

Lines 78 to 83 in 3ec7273

	const scrollToBottomForCurrentUserAction = useEffectEvent((isFromCurrentUser: boolean, action?: OnyxTypes.ReportAction) => {
	InteractionManager.runAfterInteractions(() => {
	// If a new comment is added and it's from the current user scroll to the bottom otherwise leave the user positioned where
	// they are now in the list.
	if (!isFromCurrentUser || (!isReportTopmostSplitNavigator() && !Navigation.getReportRHPActiveRoute())) {
	return;

That is why self-authored messages can still jump to the bottom while incoming messages from another participant can remain hidden until manual scroll.

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

Fix useScrollToEndOnNewMessageReceived() so an incoming live-tail scroll survives the report/action render split.

Concretely:

• When the user is already near the bottom and the newest rendered action/list size changes from a state that was at the live tail, arm a pending auto-scroll instead of requiring hasNewestReportAction to be true immediately.
• When hasNewestReportAction becomes true and the user is still near the bottom, hide the floating counter, call the supplied scrollToEnd()/scrollToBottom() callback, and clear the pending state.
• Reset the pending state and baselines when resetKey changes, and cancel the pending scroll if the user scrolls away before the metadata catches up.

Keep this in the shared hook rather than only in ReportActionsList, because MoneyRequestReportActionsList uses the same hook:

App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Lines 445 to 455 in 3ec7273

	useScrollToEndOnNewMessageReceived({
	sizeChangeType: 'grewFromReportActions',
	scrollOffsetRef,
	lastActionID: lastAction?.reportActionID,
	visibleActionsLength: visibleReportActions.length,
	reportActionsLength: reportActions.length,
	hasNewestReportAction,
	setIsFloatingMessageCounterVisible,
	scrollToEnd: reportScrollManager.scrollToEnd,
	resetKey: report?.reportID ?? reportIDFromRoute ?? '',
	});

The deep-link/pagination protection should remain: only arm the pending scroll when the user was already at the live tail, so linking to an older action or loading mid-history pages does not jump to the newest message.

Add focused coverage for both realtime update orders:

• reportActions_* receives the new incoming action before report.lastVisibleActionCreated.
• report.lastVisibleActionCreated updates before reportActions_*.

Both should scroll when the user is already at the bottom, and neither should scroll when the user is reading older messages.

What alternative solutions did you explore? (Optional)

I considered routing active-report incoming messages through notifyNewAction() and updating useReportActionsNewActionLiveTail() to scroll for other users. That is broader because it couples live-tail scrolling to notification/Pusher side effects, and it would still need careful handling for the active-report notification suppression. The list already has a shared "new message received" hook, so fixing that hook's timing assumption is the smaller and more complete change.

[melvin-bot]

Current assignee @aimane-chnaif is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[ReaperOAK]

Proposal

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

When a user is actively viewing a report at the bottom (live-tailing), a new message from another participant is appended to the list but the view does not auto-scroll to reveal it — the user must manually scroll down.

What is the root cause of that problem?

There are two code paths that could auto-scroll for incoming messages. Both fail for other-participant messages.

Path 1 — src/pages/inbox/report/useReportActionsNewActionLiveTail.ts (lines 78–84)

if (!isFromCurrentUser || (!isReportTopmostSplitNavigator() && !Navigation.getReportRHPActiveRoute())) {
    return;
}

This early return is intentional: the live-tail scroll fires only for the current user's own messages. Other-participant messages always exit here. This path is by design inert for incoming messages.

Path 2 — src/hooks/useScrollToEndOnNewMessageReceived.ts (lines 62–94) — the intended fallback

if (
    scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD &&
    previousLastIndex.current !== lastActionID &&
    didListSizeChange &&
    hasNewestReportAction &&
    prevHasNewestReportAction          // ← root cause
) {
    scrollToEnd();
}
previousLastIndex.current = lastActionID;  // ← compounding: always advances

Root cause — prevHasNewestReportAction race condition:

hasNewestReportAction is derived from lastAction.created === report.lastVisibleActionCreated. When another participant's message arrives, Onyx delivers two separate updates in distinct render cycles:

• Render A: report.lastVisibleActionCreated updates → hasNewestReportAction becomes false (new action not yet in reportActions). didListSizeChange = false. No scroll fires. previousLastIndex.current advances to lastActionID.
• Render B: new reportAction merges into the list → didListSizeChange = true, hasNewestReportAction = true, but prevHasNewestReportAction = false (was false on Render A). Gate fails. No scroll fires.

Compounding issue — unconditional previousLastIndex.current advancement:

previousLastIndex.current = lastActionID runs outside the if block unconditionally. After Render B, it has already advanced, so previousLastIndex.current !== lastActionID is permanently false for this message. No later render can retry. The auto-scroll is permanently disarmed.

The net result: no code path ever calls scrollToEnd() for a new other-participant message.

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

File: src/hooks/useScrollToEndOnNewMessageReceived.ts

The fix targets the live-tail case specifically: when the user is already at the bottom of the conversation (scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD), a new message arriving should scroll them down regardless of the prevHasNewestReportAction transition. The prevHasNewestReportAction guard was introduced to prevent spurious scrolls when the user navigates to a conversation that already has the newest action loaded — at that moment hasNewestReportAction transitions false → true without a new message arriving. We must distinguish these two cases.

The key insight: the previousLastIndex.current !== lastActionID check already handles the "no new message" case — if no new action arrived, lastActionID doesn't change, so the guard holds. The prevHasNewestReportAction guard is therefore redundant for preventing navigation-triggered spurious scrolls when the user is at the bottom, because in the navigation case didListSizeChange would also be false (no new action in the list). We can safely remove prevHasNewestReportAction from the conjunction without causing spurious scrolls during navigation.

To prevent multiple fires for the same message (the loop risk raised in the critique), we move `previousLastIndex.current = lastActionID

[wildan-m]

Proposal

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

When the user is actively viewing a report and a new message arrives from another participant, the report does not auto-scroll to the bottom to reveal the new message. The user is left at their current scroll position and has to scroll down manually. This only affects messages received from other participants while the report is open and the user is already at the bottom (live-tail).

What is the root cause of that problem?

Auto-scrolling the open report to a newly received message is driven by the useScrollToEndOnNewMessageReceived hook. (The other scroll path — the Pusher subscribeToNewActionEvent subscription in useReportActionsNewActionLiveTail — intentionally does nothing for messages from other participants: its handler returns early when isFromCurrentUser is false, by design "leave the user positioned where they are now". So auto-scroll for incoming messages depends entirely on useScrollToEndOnNewMessageReceived.)

That hook only scrolls when all of these are true at the render where the new action appears:

App/src/hooks/useScrollToEndOnNewMessageReceived.ts

Lines 62 to 80 in 3ec7273

	useEffect(() => {
	const didListSizeChange = sizeChangeType === 'grewFromReportActions' ? reportActionSize.current > (reportActionsLength ?? 0) : reportActionSize.current !== visibleActionsLength;
	if (
	scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD &&
	previousLastIndex.current !== lastActionID &&
	didListSizeChange &&
	hasNewestReportAction &&
	// We don't want to trigger a scroll to the end if the
	// user was not already close to the end of the chat.
	// When we link to a specific report action and there are
	// no report actions in Onyx, the report action pages might
	// merge, which would cause a scroll to the end otherwise.
	prevHasNewestReportAction
	) {
	setIsFloatingMessageCounterVisible(false);
	scrollToEnd();
	}

• the user is near the bottom,
• the last action ID changed,
• the visible list grew,
• hasNewestReportAction is true now, and
• prevHasNewestReportAction (the value from the previous render) was also true.

The last guard exists to avoid an unwanted scroll when comment-linking causes report-action pages to merge.

hasNewestReportAction is computed with a strict equality between the last loaded action's timestamp and the report's lastVisibleActionCreated:

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

Lines 434 to 435 in 3ec7273

	const lastVisibleActionCreated = getReportLastVisibleActionCreated(report, transactionThreadReport);
	const hasNewestReportAction = lastAction?.created === lastVisibleActionCreated || isReportPreviewAction(lastAction);

The two values come from two different Onyx keys: the last loaded action comes from the reportActions_<reportID> collection, while lastVisibleActionCreated comes from the report_<reportID> metadata. When a message arrives from another participant, the new action is merged into the loaded reportActions a render before the report's lastVisibleActionCreated metadata catches up. During that render the last loaded action is newer than lastVisibleActionCreated, so created === lastVisibleActionCreated is false and hasNewestReportAction briefly flips to false.

Because the hook reads prevHasNewestReportAction from the previous render, that transient false poisons the guard: on the render where the new message becomes visible and the list grows, prevHasNewestReportAction is false, so the scroll is suppressed. The report stays put.

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

Make hasNewestReportAction robust to the metadata lag by treating "we have the newest action loaded" as the last loaded action is at least as new as the report's last-visible-action marker, instead of requiring an exact timestamp match.

Concretely, in src/pages/inbox/report/ReportActionsList.tsx change the hasNewestReportAction comparison from strict-equals to greater-than-or-equal:

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

Lines 434 to 435 in 3ec7273

	const lastVisibleActionCreated = getReportLastVisibleActionCreated(report, transactionThreadReport);
	const hasNewestReportAction = lastAction?.created === lastVisibleActionCreated || isReportPreviewAction(lastAction);

so it reads, in effect, "the last loaded action's created is >= lastVisibleActionCreated" (string comparison is already used for these DB timestamps elsewhere, e.g. the unread-marker effect and getReportLastVisibleActionCreated itself).

This changes behavior in exactly one direction: it only flips hasNewestReportAction from false to true in the case where the last loaded action is newer than the report metadata — i.e. a freshly arrived message whose metadata hasn't caught up yet, which is precisely the case where we genuinely do have the newest action. It never reports "have newest" when there are truly newer, not-yet-loaded actions on the server (in that case the loaded action is older than lastVisibleActionCreated, so >= is still false). With the transient false gone, prevHasNewestReportAction stays true across the incoming-message render, and useScrollToEndOnNewMessageReceived fires the live-tail scroll as intended.

The comment-linking guard is unaffected: when linking to an older action, the last loaded action is older than the report's true newest, so hasNewestReportAction (and therefore prevHasNewestReportAction) remains false and the merge-time scroll is still suppressed.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/92151-autoscroll-incoming-message?expand=1

What alternative solutions did you explore? (Optional)

• Localize the fix inside useScrollToEndOnNewMessageReceived by deriving the "were we at live-tail" baseline from the offset and last-action refs at the last structural change, instead of from the immediately-previous render's hasNewestReportAction. This works but adds state to the hook and is more invasive than correcting the single source of the transient-false value.
• Drop the prevHasNewestReportAction guard entirely and rely only on the near-bottom offset check. Rejected because the guard still has value for the link-to-newest page-merge case, and removing it risks reintroducing the unwanted scroll the guard was added to prevent.

[aswin-s]

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

When a user is actively viewing a report and another participant sends a new message, the report fails to auto-scroll to reveal it. The user must scroll down manually. Expected: the list should scroll to the bottom as soon as the new action is appended, since the user was already at the newest message.

What is the root cause of that problem?

In src/hooks/useScrollToEndOnNewMessageReceived.ts:65-76, the auto-scroll predicate requires both hasNewestReportAction AND prevHasNewestReportAction to be true. hasNewestReportAction is computed in src/pages/inbox/report/ReportActionsList.tsx:435 as lastAction?.created === lastVisibleActionCreated, i.e. strict equality between two values sourced from independent Onyx keys (reportActions_<id> collection and report.lastVisibleActionCreated). When an incoming action arrives from another user, those two Onyx writes are not delivered atomically: for at least one render, lastAction.created (the just-appended action) differs from report.lastVisibleActionCreated, so hasNewestReportAction flickers to false.

On that transient-false render the effect body still runs to completion, advancing the baselines unconditionally at lines 81–82:

previousLastIndex.current = lastActionID;
reportActionSize.current = visibleActionsLength;

So on the subsequent render — when both Onyx keys have settled and hasNewestReportAction is again true — previousLastIndex.current already equals lastActionID and reportActionSize.current already equals visibleActionsLength. Both the previousLastIndex.current !== lastActionID guard (line 67) and the didListSizeChange guard (line 63) evaluate to false, so scrollToEnd() (line 78) never fires for that incoming message. The prevHasNewestReportAction latch compounds the failure but is not the primary blocker; the advanced baselines alone prevent scroll from firing even if that latch is patched independently.

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

The core fix is to make baseline advancement conditional: only advance previousLastIndex and reportActionSize when the scroll guard either fired or was legitimately bypassed (i.e. the user was not near the bottom, or there was no new action). Baselines must not advance on a render where hasNewestReportAction is transiently false while a new action is in-flight, because that consumes the "changed" state before the settled render can act on it.

Change 1 — src/hooks/useScrollToEndOnNewMessageReceived.ts, lines 62–82

Gate baseline advancement on hasNewestReportAction so that a transient-false render does not consume the size/index change before the settled render can scroll:

useEffect(() => {
    const didListSizeChange =
        sizeChangeType === 'grewFromReportActions'
            ? reportActionSize.current > (reportActionsLength ?? 0)
            : reportActionSize.current !== visibleActionsLength;

    const shouldScroll =
        scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD &&
        previousLastIndex.current !== lastActionID &&
        didListSizeChange &&
        hasNewestReportAction &&
        prevHasNewestReportAction;

    if (shouldScroll) {
        setIsFloatingMessageCounterVisible(false);
        scrollToEnd();
    }

    // Only advance baselines when hasNewestReportAction is stable-true,
    // or when the user is clearly not at the bottom (scroll guard failed for
    // a non-transient reason). If hasNewestReportAction is transiently false
    // while a new action is still settling, preserve the current baselines so
    // the next render can still detect the change.
    if (hasNewestReportAction || scrollOffsetRef.current >= AUTOSCROLL_TO_TOP_THRESHOLD) {
        previousLastIndex.current = lastActionID;
        reportActionSize.current = visibleActionsLength;
    }
}, [
    scrollOffsetRef,
    lastActionID,
    reportActionsLength,
    visibleActionsLength,
    hasNewestReportAction,
    prevHasNewestReportAction,
    sizeChangeType,
    resetKey,
    setIsFloatingMessageCounterVisible,
    scrollToEnd,
]);

Change 2 — src/pages/inbox/report/ReportActionsList.tsx:435 and the twin at src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx:198

As a complementary defence, widen the hasNewestReportAction predicate from strict equality to >= so that a newly arrived action (whose timestamp will be at least as recent as the stale lastVisibleActionCreated) is not treated as "not at newest":

// Before
const hasNewestReportAction = lastAction?.created === lastVisibleActionCreated;

// After
const hasNewestReportAction = !!lastAction?.created && lastAction.created >= lastVisibleActionCreated;

Apply the same change to the money-request report twin call-site at src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx:445 so the fix covers both inbox chat reports and money-request reports across all platforms.

Change 3 — regression test

Add a test that simulates a Pusher action arriving with a one-render delay between reportActions and report.lastVisibleActionCreated updates, asserting scrollToEnd is still called:

• Render the hook with hasNewestReportAction = true, lastActionID = 'A', visibleActionsLength = 5.
• Simulate the transient-false render: update lastActionID to 'B' and visibleActionsLength to 6, but flip hasNewestReportAction to false (Onyx desync in progress).
• Assert scrollToEnd has NOT been called yet.
• Simulate the settled render: flip hasNewestReportAction back to true, keeping lastActionID = 'B' and visibleActionsLength = 6.
• Assert scrollToEnd has been called exactly once.

This test is the minimal reproducer of the race condition and guards against any future refactor that reintroduces unconditional baseline advancement.

What alternative solutions did you explore? (Optional)

Replacing usePrevious(hasNewestReportAction) with a sticky ref that is set to true once hasNewestReportAction becomes true and only reset on resetKey change or when the user scrolls past AUTOSCROLL_TO_TOP_THRESHOLD would absorb the transient desync without re-introducing scroll-on-pagination-merge. However, this change addresses only the prevHasNewestReportAction guard and does not prevent the baselines from advancing during the transient-false render; by itself it does not unblock the previousLastIndex and didListSizeChange guards, so the scroll would still not fire.

Snapshotting hasNewestReportAction only when lastActionID changes (rather than every render) would also avoid the transient-flicker capture, but it conflates two concerns and is brittle if Onyx ordering changes again.

Forcing atomic Onyx batching of report.lastVisibleActionCreated and reportActions_<id> writes would fix it at the source but is a backend-shaped change outside the frontend scope.

[KJ21-ENG]

Updated my proposal: active incoming messages need the shared useScrollToEndOnNewMessageReceived timing fix, not only a subscriber change.

[Abdulloh0109]

What is the root cause of that problem?

Auto-scroll for a message from another participant can only come from the render-driven hook useScrollToEndOnNewMessageReceived, wired up here:

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

Lines 474 to 484 in 3ec7273

	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}`,
	});

The subscriber path in useReportActionsNewActionLiveTail cannot do it. Its handler returns immediately when the action isn't the current user's:

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

Lines 78 to 84 in 3ec7273

	const scrollToBottomForCurrentUserAction = useEffectEvent((isFromCurrentUser: boolean, action?: OnyxTypes.ReportAction) => {
	InteractionManager.runAfterInteractions(() => {
	// If a new comment is added and it's from the current user scroll to the bottom otherwise leave the user positioned where
	// they are now in the list.
	if (!isFromCurrentUser || (!isReportTopmostSplitNavigator() && !Navigation.getReportRHPActiveRoute())) {
	return;
	}

and in practice it's never even invoked for an incoming message — every notifyNewAction(...) call site passes true or actorAccountID === currentUserAccountID, i.e. only current-user comment-creation actions trigger it; a message pushed in over Pusher from someone else doesn't call it at all:

App/src/libs/actions/Report/index.ts

Lines 751 to 762 in 3ec7273

	/** Notify the ReportActionsView that a new comment has arrived */
	function notifyNewAction(reportID: string | string[] | undefined, reportAction: ReportAction | undefined, isFromCurrentUser: boolean) {
	if (!reportID) {
	return;
	}
	const ids = Array.isArray(reportID) ? reportID : [reportID];
	for (const id of ids) {
	const actionSubscriber = newActionSubscribers.find((subscriber) => subscriber.reportID === id);
	if (actionSubscriber) {
	actionSubscriber.callback(isFromCurrentUser, reportAction);
	}

So incoming-message scroll lives or dies entirely on the hook. Its gate, plus an unconditional baseline advance right after it:

App/src/hooks/useScrollToEndOnNewMessageReceived.ts

Lines 62 to 94 in 3ec7273

	useEffect(() => {
	const didListSizeChange = sizeChangeType === 'grewFromReportActions' ? reportActionSize.current > (reportActionsLength ?? 0) : reportActionSize.current !== visibleActionsLength;
	if (
	scrollOffsetRef.current < AUTOSCROLL_TO_TOP_THRESHOLD &&
	previousLastIndex.current !== lastActionID &&
	didListSizeChange &&
	hasNewestReportAction &&
	// We don't want to trigger a scroll to the end if the
	// user was not already close to the end of the chat.
	// When we link to a specific report action and there are
	// no report actions in Onyx, the report action pages might
	// merge, which would cause a scroll to the end otherwise.
	prevHasNewestReportAction
	) {
	setIsFloatingMessageCounterVisible(false);
	scrollToEnd();
	}
	previousLastIndex.current = lastActionID;
	reportActionSize.current = visibleActionsLength;
	}, [
	scrollOffsetRef,
	lastActionID,
	reportActionsLength,
	visibleActionsLength,
	hasNewestReportAction,
	prevHasNewestReportAction,
	sizeChangeType,
	resetKey,
	setIsFloatingMessageCounterVisible,
	scrollToEnd,
	]);

requires, on the same render: near the live tail (scrollOffsetRef < 250), previousLastIndex.current !== lastActionID, the list grew, hasNewestReportAction, and prevHasNewestReportAction (the previous render's value). Then it advances previousLastIndex.current and reportActionSize.current on every render.

If the new action and its metadata landed in one render, this gate would pass and scroll — I traced it. They don't. lastAction comes from the reportActions_<id> collection, while hasNewestReportAction compares lastAction.created against report.lastVisibleActionCreated, a field on the separate report_<id> key:

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

Lines 434 to 435 in 3ec7273

	const lastVisibleActionCreated = getReportLastVisibleActionCreated(report, transactionThreadReport);
	const hasNewestReportAction = lastAction?.created === lastVisibleActionCreated || isReportPreviewAction(lastAction);

While those two Onyx writes settle there is at least one render where the new action is present but hasNewestReportAction is momentarily false. That transient defeats the gate two different ways depending on which key wins the race:

• reportActions_<id> settles first — render N has the new action and the grown list, but hasNewestReportAction = false, so no scroll. The unconditional advance then moves previousLastIndex/reportActionSize onto the new action. Render N+1 has hasNewestReportAction = true, but now previousLastIndex.current === lastActionID and didListSizeChange is false. The change was consumed; the scroll can never re-fire.
• report.lastVisibleActionCreated settles first — the new action arrives a render later, where hasNewestReportAction is true again, but prevHasNewestReportAction is false (it was the transient-false render), so the prevHasNewestReportAction conjunct blocks it.

Either way the scroll is permanently disarmed for that message and the view stays put. Self-sent messages are unaffected because the subscriber path scrolls those — which is exactly why only other-participant messages are stuck.

Both the prevHasNewestReportAction conjunct and the unconditional baseline advance were introduced together in 2b34517c37e ("refactor: extract scroll to bottom effect and prevent on comment linking").

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

Fix the hook (state/effect layer). Both fragilities have to be addressed — I checked each in isolation and fixing only one leaves the other render ordering broken:

1. Advance the baselines only when the scroll actually fires, or when the user is genuinely not near the live tail (gate failed for a non-transient reason) — not on every render. This stops a transient-false render from consuming the previousLastIndex/size change, so the settled render can still catch it. (fixes the reportActions-first ordering)
2. Drop the prevHasNewestReportAction conjunct. (fixes the metadata-first ordering)

Dropping it is safe: that conjunct existed to avoid a spurious scroll when comment-linking merges report-action pages, but that case is already covered without it. When you link to an older action the loaded last action isn't the report's newest, so hasNewestReportAction is itself false and the gate won't fire; and resetKey (= reportID:linkedReportActionID) already resets the baselines whenever the linked action changes:

App/src/hooks/useScrollToEndOnNewMessageReceived.ts

Lines 50 to 60 in 3ec7273

	useLayoutEffect(() => {
	if (resetKey === undefined) {
	return;
	}
	if (previousResetKeyRef.current === resetKey) {
	return;
	}
	previousResetKeyRef.current = resetKey;
	previousLastIndex.current = lastActionID;
	reportActionSize.current = visibleActionsLength;
	}, [resetKey, lastActionID, visibleActionsLength]);

So prevHasNewestReportAction is now redundant with the near-bottom guard + hasNewestReportAction + resetKey.

Keep the change in the shared hook so both the inbox list (link above) and the money-request twin get it — the latter passes sizeChangeType: 'grewFromReportActions', so the conditional baseline advance has to respect both sizeChangeType branches:

App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Lines 445 to 455 in 3ec7273

	useScrollToEndOnNewMessageReceived({
	sizeChangeType: 'grewFromReportActions',
	scrollOffsetRef,
	lastActionID: lastAction?.reportActionID,
	visibleActionsLength: visibleReportActions.length,
	reportActionsLength: reportActions.length,
	hasNewestReportAction,
	setIsFloatingMessageCounterVisible,
	scrollToEnd: reportScrollManager.scrollToEnd,
	resetKey: report?.reportID ?? reportIDFromRoute ?? '',
	});

Edge cases this touches: comment-linking stays suppressed (covered above), and the scrollOffsetRef < AUTOSCROLL_TO_TOP_THRESHOLD near-bottom guard stays, so a user reading older history isn't yanked to the bottom.

One honesty note: the gate provably suppresses the scroll on any multi-render settle; the precise key interleaving is timing-dependent, so I'd confirm with a one-line log on hasNewestReportAction/prevHasNewestReportAction when a Pusher action lands during implementation. The fix is robust to either order regardless.

What alternative solutions did you explore? (Optional)

• Widen hasNewestReportAction from === to >= in ReportActionsList (L434-L435). Rejected as incomplete: >= only neutralizes the transient when the action lands before the metadata (new.created >= stale lastVisibleActionCreated → true). In the opposite order — report.lastVisibleActionCreated updates first while reportActions still ends on the old action — lastAction.created is the older timestamp, so older >= newer is still false and the transient (plus the prevHasNewestReportAction poisoning) survives. It also never touches the unconditional baseline advance, which independently kills the action-first order.
• Gate the baseline advance on hasNewestReportAction but keep prevHasNewestReportAction. Rejected for the same metadata-first reason: keeping the conjunct means a single transient-false render still poisons the next render's gate, so the scroll is blocked even though the baselines were preserved.
• Route incoming messages through notifyNewAction and let the subscriber scroll for other users. Rejected: it couples live-tail scrolling to the notification/Pusher side-effect path and has to fight the active-report notification suppression. The render-driven hook already exists for exactly this and is the more local change.