[$250] Concierge - GetOlderActions isn't called after clicking Show history

[applause-bot]

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

---

Version Number: v9.4.20-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: #94444
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

Preconditions:

• Have Concierge chat with long and hidden history (Show history button is shown)
• Open Network tab on Chrome DevTools

Steps:

1. Open the Concierge chat
2. Make sure there is no GetOlderActions API calls in the Network tab
3. Tap on Show history and scroll to top

Expected Result:

GetOlderActions should be called after clicking Show history and scroll to top

Actual Result:

GetOlderActions isn't called after clicking Show history and scroll to top

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7191580_1782441295688.concierge.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070383777698385871
• Upwork Job ID: 2070383777698385871
• Last Price Increase: 2026-06-26

Issue Owner

Current Issue Owner: @VickyStash

[applause-bot]

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

https://platform.applause.com/services/links/v1/external/a1e034d9ab784d5179d5c2e549e5a4c25954da70f52473c01a1d1de5b5e16595

[MelvinBot]

Proposal

This is a regression from #94444 (merged 2026-06-25), which is the exact PR linked in this report's "caught during" field. That PR touched only ReportActionsList.tsx and its reproduction steps are identical to this issue.

What is the root cause of that problem?

PR #94444 fixed an infinite-GetOlderActions loop on hidden Concierge history by wrapping onEndReached so it no-ops while history is hidden:

const loadOlderChatsOnEndReached = () => {
    if (showHiddenHistory) {  // isConciergeHiddenHistory && !showFullHistory
        return;
    }
    loadOlderChats(false);
};

ReportActionsList.tsx:313-318

The showHiddenHistory boolean itself is correct — after the user clicks Show history, handleShowPreviousMessages sets showFullHistory = true, so showHiddenHistory flips to false and the guard should fall through. The breakage is a side effect of turning onEndReached into a no-op, not the boolean logic:

The list is an inverted FlashList v2. It fires onEndReached only on the rising edge (when you newly enter the end-threshold) and tracks an internal pendingEndReached flag that is only reset to false when the rendered data array reference changes. When Concierge opens with hidden history the visible list is short (pre-session actions are filtered out, useConciergeSidePanelReportActions.ts:156-173), so the list is already at the end on mount and fires onEndReached once — which now returns early without changing any data. pendingEndReached is left stuck true. Previously the unconditional loadOlderChats(false) always fetched a page, which changed data and naturally re-armed the callback; the no-op removed that side effect, so on later scroll-to-top onEndReached never re-fires and GetOlderActions is never dispatched.

Evidence chain + the secondary candidate mechanism

• FlashList v2 arming logic (node_modules/@shopify/flash-list/.../useBoundDetection.js): if (isNearEnd && !pendingEndReached.current) { pendingEndReached.current = true; onEndReached(); } then pendingEndReached.current = isNearEnd, with useMemo(() => { pendingEndReached.current = false; }, [data]). Re-arm is gated on the data reference (renderedVisibleReportActions).
• loadOlderChats → getOlderActions → API.paginate(GET_OLDER_ACTIONS). The force flag only bypasses the offline check; it still requires hasOlderActions. There is no internal debounce/loading guard, so the suppression genuinely lives in the onEndReached wrapper.
• The original loop: hidden pre-session pages are filtered out of the visible list, so fetched pages never lengthen it, the end-threshold stays satisfied, and onEndReached keeps firing — the loop Prevent loading older chats while hidden history is shown #94444 was guarding against.
• Secondary candidate (needs device confirmation): showFullHistory could also be getting reset back to false after the click (e.g. a startSession/sessionStartTime re-run at ConciergeSessionContext.tsx:98-99 or the local resets in useConciergeSidePanelReportActions.ts:56-63), which would re-block the guard. Either way the culprit is the same wrapper; logging showFullHistory/showHiddenHistory and whether onEndReached is re-entered during the repro will distinguish the two.

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

Stop the loop at the fetch layer instead of by no-op'ing the list callback, so onEndReached keeps firing/clearing FlashList's edge state normally while the actual GetOlderActions request is what's gated:

1. Revert onEndReached back to always invoking loadOlderChats (remove the early-return wrapper), and
2. Move the hidden-history block into loadOlderChats in useLoadReportActions.ts, keyed on the same showFullHistory state and bypassed by force === true. The Show history reveal already calls loadOlderChats(true) (force), so it pages normally; subsequent onEndReached (force=false) is blocked only while history is genuinely hidden.

This keeps the #94444 loop fix while ensuring that once history is revealed, scroll-to-top pagination works because the list's onEndReached was never left in a stranded state.

⚠️ The root-cause culprit (PR #94444's onEndReached wrapper) is confirmed with high confidence, but there are two candidate runtime mechanisms (FlashList re-arm vs. showFullHistory reset). The author should reproduce on web with the above instrumentation to confirm which, and verify the fix doesn't reintroduce the original loop.

Related issue

• Original loop this regressed from: #94444 (fixed the onEndReached loop) — the most likely owner is the PR author, VickyStash.

---

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

[MobileMage]

Proposal

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

In a Concierge chat with long, hidden history, after tapping Show history and scrolling to the top, GetOlderActions is never fired, so the older messages above the revealed session never paginate in. This is a regression from PR #94444, which was caught during that PR's own QA.

What is the root cause of that problem?

PR #94444 fixed an onEndReached loop (#93916) by wrapping the pagination trigger in a guard that returns early whenever showHiddenHistory is truthy:

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

Lines 313 to 318 in 7e43cce

	const loadOlderChatsOnEndReached = () => {
	if (showHiddenHistory) {
	return;
	}
	loadOlderChats(false);
	};

showHiddenHistory is isConciergeHiddenHistory && !showFullHistory (set in ReportActionsView). While history is hidden, filterActions in useConciergeSidePanelReportActions collapses the rendered list down to just the current-session actions, so renderedVisibleReportActions is a short set and, in the inverted FlashList, its end (the top) sits permanently inside onEndReachedThreshold (0.75).

The breakage comes from how FlashList v2 tracks the end-reached event. In useBoundDetection.checkBounds, once onEndReached() fires it sets pendingEndReached.current = isNearEnd, and that flag is only reset back to false when the data array reference changes:

if (isNearEnd && !pendingEndReached.current) { pendingEndReached.current = true; onEndReached(); }
pendingEndReached.current = isNearEnd;            // stays true while still near the end
// reset only on data change:
useMemo(() => { pendingEndReached.current = false; }, [data]);

While history is hidden, the guard swallows every onEndReached call, so loadOlderChats never runs and no new actions are ever appended — data (renderedVisibleReportActions) stays the same short loaded set. After tapping Show history, handleShowPreviousMessages does setShowFullHistory(true) plus a single forced loadOlderChats(true), which fires onEndReached once and re-arms pendingEndReached.current = true. From that point the user is still near the end, isNearEnd stays true, and because the guard had prevented any prefetch the loaded set doesn't grow further on that tick — so pendingEndReached is never reset and scrolling to the top can no longer re-trigger onEndReached. The guard solved the loop but left the list permanently end-blocked once revealed.

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

The guard is too broad — it blocks onEndReached entirely while hidden, which is what starves FlashList of the data-change needed to re-arm pagination. The loop in #93916 happened because, while hidden, loadOlderChats fetched older actions that filterActions then hid, keeping the list short and re-firing onEndReached indefinitely. We can keep blocking that loop without blocking pagination after reveal by gating on showFullHistory directly inside handleShowPreviousMessages's flow and letting onEndReached resume normally once revealed. Concretely, drop the unconditional early-return and make the trigger fire whenever history is no longer hidden, while still suppressing the loop during the hidden phase:

const loadOlderChatsOnEndReached = () => {
    // While the session view is collapsed we intentionally don't prefetch
    // older actions (they'd be hidden and re-trigger onEndReached in a loop).
    // Once the user reveals history (showHiddenHistory === false), paginate normally.
    if (showHiddenHistory) {
        return;
    }
    loadOlderChats(false);
};

Because the regression is that the revealed state never re-arms, the real fix is in handleShowPreviousMessages: after setShowFullHistory(true), the list data widens to the full set, which changes the data reference and resets pendingEndReached. The forced loadOlderChats(true) already kicks the first page. To guarantee subsequent pages, we should make the reveal not depend on a single forced call by allowing onEndReached to run once showHiddenHistory flips false — i.e. the guard above is correct as written, but the loop must instead be broken by not calling loadOlderChats during the hidden phase only, which it already does. This keeps the #93916 loop fixed (hidden phase still returns early) and restores pagination after reveal because showHiddenHistory is now false and loadOlderChats(false) runs on every legitimate onEndReached. loadOlderChats itself still self-guards on !hasOlderActions and offline, so no other caller is affected.

What alternative solutions did you explore? (Optional)

Patching FlashList to reset pendingEndReached on a showFullHistory transition (via a key/remount of the list) — rejected because remounting the report list on reveal would lose scroll position and is far more invasive than scoping the existing guard to only the genuinely-hidden phase.

[lorretheboy]

Proposal

What is the root cause of that problem?

PR #94444 changed onEndReached to early-return whenever showHiddenHistory is true:

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

Lines 313 to 318 in 7e43cce

	const loadOlderChatsOnEndReached = () => {
	if (showHiddenHistory) {
	return;
	}
	loadOlderChats(false);
	};

showHiddenHistory is derived as isConciergeHiddenHistory && !showFullHistory:

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

Line 251 in 7e43cce

showHiddenHistory={isConciergeHiddenHistory && !showFullHistory}

While history is collapsed, the filtered list only contains the current session's messages, so it is short and stays pinned to the end of the inverted list. onEndReached fires there and is now swallowed by the guard. Because nothing is ever appended, the list's content size and end position never change, so FlashList keeps treating onEndReached as already‑dispatched for that position and will not emit it again.

Tapping "Show history" runs handleShowPreviousMessages, which flips showFullHistory to true (making showHiddenHistory false) and reveals the already‑loaded pre‑session messages:

App/src/hooks/useConciergeSidePanelReportActions.ts

Lines 181 to 184 in 7e43cce

	const handleShowPreviousMessages = useCallback(() => {
	setShowFullHistory(true);
	loadOlderChats(true);
	}, [setShowFullHistory, loadOlderChats]);

But revealing collapsed-but-already-loaded actions appends no new page, so FlashList's onEndReached latch is never reset. Scrolling back to the top therefore never re-fires onEndReached, loadOlderChats is never called, and GetOlderActions is never sent. So the guard, which was meant only to stop the auto-load loop while collapsed, also permanently kills pagination once the user expands the history.

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

Don't suppress the onEndReached event itself — that is what leaves FlashList latched. Instead let the handler always run and gate the loading loop at the point that actually caused it: only skip the fetch while history is hidden, and re-arm pagination when the user reveals history.

Concretely, when history is revealed in handleShowPreviousMessages, drive the next page explicitly (it already calls loadOlderChats(true)), and make onEndReached resume working afterward by not returning a dead callback — e.g. keep calling loadOlderChats(false) here once showHiddenHistory is false, and force a re-arm of the list on the collapse→expand transition (the existing listID remount key, or toggling onEndReached identity) so a scroll-to-top after expanding re-emits onEndReached:

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

Line 512 in 7e43cce

onEndReached={loadOlderChatsOnEndReached}

This preserves the loop fix (no loading while collapsed) while restoring normal older-page pagination after "Show history".

What alternative solutions did you explore? (Optional)

Keep the guard but include the reveal transition in listID so the list remounts when showFullHistory flips true, which resets FlashList's onEndReached latch and lets scroll-to-top paginate again.

[aswin-s]

Proposal

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

When a user opens the Concierge chat with hidden history and taps "Show history", scrolling to the top no longer triggers GetOlderActions. The expected behavior is that after the user reveals history, scrolling to the top should load older chat messages via GetOlderActions as it did before.

What is the root cause of that problem?

PR #94444 introduced loadOlderChatsOnEndReached in src/pages/inbox/report/ReportActionsList.tsx (lines 313–318) which returns early without calling loadOlderChats whenever showHiddenHistory is true. However, showHiddenHistory remains true even after the user taps "Show history" — the guard was intended to suppress pagination before the history is revealed, but it instead permanently blocks GetOlderActions for the entire session, even after history is shown via onShowPreviousMessages.

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

1. src/pages/inbox/report/ReportActionsList.tsx lines 313–318 — Change the guard condition from if (showHiddenHistory) to if (showHiddenHistory && !hasPreviousMessages), or alternatively invert the logic to only suppress loadOlderChats when history is actively hidden AND the "Show history" button has not yet been pressed (i.e., check whether the user has already revealed history via onShowPreviousMessages).
2. src/pages/inbox/report/ReportActionsList.tsx — Alternatively, replace the showHiddenHistory prop check with a local state variable (e.g., hasRevealedHistory) that starts as false and flips to true when onShowPreviousMessages is called, so the guard only blocks loadOlderChats before the user taps "Show history", not after.
3. Verify the fix covers the ShowPreviousMessagesButton flow (line 414) so that showFullHistory={!showHiddenHistory} and the pagination guard remain in sync after the reveal.

What alternative solutions did you explore? (Optional)

Revert onEndReached to call loadOlderChats(false) directly (removing the guard entirely) — this would fix the regression but may re-introduce whatever original issue PR #94444 was solving if the guard has a valid purpose before history is revealed.

[melvin-bot]

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

[kitvasyl]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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