[Due for payment 2026-07-17] [$250] Forward/Back navigation buttons disappear after submitting a report

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.9-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @JmillsExpensify
Slack conversation (hyperlinked to channel name): #QA channel

Action Performed:

1. Navigate to a workspace chat.
2. Create 3 reports containing manual expenses.
3. Navigate to Spend > Drafts.
4. Open one of the reports from the list.
5. Observe the Forward/Back navigation buttons in the top navigation area.
6. Click Submit.
7. Observe the top navigation area again.

Expected Result:

The Forward/Back navigation buttons should remain visible after submitting the report, allowing the user to navigate to the previous or next report in the filtered list.

Actual Result:

The Forward/Back navigation buttons disappear after clicking Submit.
The same behavior is observed in:
Spend > Needs Approval
Spend > Ready to Pay

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.3025.mp4

Recording.3026.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067003975317251688
• Upwork Job ID: 2067003975317251688
• Last Price Increase: 2026-06-23

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The Forward/Back arrows are rendered by MoneyRequestReportNavigation.tsx. That component already has logic meant to keep the arrows visible after a report drops out of the search results: a useState cache called lastValidReports inside MoneyRequestReportNavigationContent. The cache works in isolation, but it is destroyed by a component remount in this exact flow:

1. You open a report from a Spend view — the fast path renders MoneyRequestReportNavigationContent directly (line ~252). The cache is seeded with the live list of reports and the arrows show.
2. You click Submit (or Pay). After the write, the button fires a search() reload (SubmitPrimaryAction.tsx:110-119), which merges search.isLoading: true into the snapshot (Search.ts:519-558).
3. isSearchLoading flips to true, so the component switches from the fast path to the MoneyRequestReportNavigationStandalone branch (line ~264), which renders its own separate MoneyRequestReportNavigationContent instance.
4. These two MoneyRequestReportNavigationContent are siblings at different positions in the JSX tree, so React unmounts one and mounts the other — discarding the lastValidReports cache (it’s per-instance useState).
5. The fresh instance starts with lastValidReports = null, and the just-submitted report is no longer in the snapshot, so currentIndex === -1 and shouldDisplayNavigationArrows becomes false. The arrows disappear.

The shouldKeepMounted latch correctly keeps the outer tree mounted, but it does nothing to preserve the cache across the inner fast-path ↔ standalone swap.

Evidence & things ruled out

• All three Spend views (Drafts/Needs Approval/Ready to Pay) use type: EXPENSE_REPORT (SearchUIUtils.ts:750-819), so the outer selectIsExpenseReportSearch guard passes — not the cause.
• REPORT_NAVIGATION_LAST_SEARCH_QUERY is not cleared by submit/approve/pay (the only clearLastSearchParams caller is the FAB "Create report" menu), so lastSearchQuery.queryJSON stays defined — not the cause.
• Submit and Pay both fire search() and toggle isSearchLoading. The in-report Approve button doesn’t call search() directly, but the approved report still drops out of the filtered result set, which can take allReports.length to 0 and flip the same fast-path condition (allReports.length > 0 && !isSearchLoading) — producing the same remount. This explains why all three Spend views are affected.

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

Stop letting the fast-path/standalone fork remount MoneyRequestReportNavigationContent. Concretely, lift the lastValidReports cache out of MoneyRequestReportNavigationContent so it survives the branch swap. Two viable approaches:

• Preferred: Always render a single MoneyRequestReportNavigationContent at one fixed tree position, and conditionally feed it either the context-derived sortedReportIDs (fast path) or the useSearchSections result (standalone). This removes the structural fork entirely, so no remount happens and the existing cache logic just works.
• Alternative: Move lastValidReports (and the isSameReportList seeding logic) up into the outer MoneyRequestReportNavigation component next to the existing shouldKeepMounted latch, and pass the cached list down as a prop to whichever child renders.

What alternative solutions did you explore? (Optional)

Keying both branches with a shared key prop won’t help — they’re different component types at different positions. The real fix is to remove the remount or hoist the state above it.

---

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

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-17 02:58:55 UTC.

Proposal

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

When a report is opened from a "Spend" tab (Drafts, Needs approval, Ready to pay) and the user takes the primary action on it (Submit / Approve / Pay), the prev/next report navigation arrows in the report header disappear. The arrows should stay so the user can keep moving through the rest of the filtered list after acting on the current report.

What is the root cause of that problem?

The three affected tabs are the to-do searches, not generic snapshot searches. In en.ts the labels map directly: submit: 'Drafts', approve: 'Needs approval', pay: 'Ready to pay'. Each of those SEARCH_KEYS is built with type: EXPENSE_REPORT and an action filter, and crucially they are members of TODO_SEARCH_KEYS. For to-do searches, SearchResultsProvider sets shouldUseLiveData = true and feeds the list from useTodos() (the DERIVED.TODOS Onyx value) instead of an API snapshot. That derived value buckets each report by recomputing isSubmitAction()/isApproveAction()/isPrimaryPayAction() on every REPORT change:

App/src/libs/actions/OnyxDerived/configs/todos.ts

Lines 62 to 66 in ec76752

	if (isSubmitAction(report, reportTransactions, reportMetadata, policy, reportNameValuePair, undefined, login, currentUserAccountID) && !allExpensesHeld) {
	reportsToSubmit.push(report);
	}
	if (isApproveAction(report, reportTransactions, currentUserAccountID, reportMetadata, policy) && !allExpensesHeld) {
	reportsToApprove.push(report);

When the user submits, submitReport optimistically writes the new state onto the report:

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 1392 to 1393 in ec76752

	stateNum: CONST.REPORT.STATE_NUM.SUBMITTED,
	statusNum: CONST.REPORT.STATUS_NUM.SUBMITTED,

That recomputes DERIVED.TODOS, isSubmitAction(report, …) now returns false, and the report drops out of reportsToSubmit immediately. The SEARCH_MONEY_REQUEST_REPORT view is an RHP modal layered over the still-mounted Search page, so Search/index.tsx keeps running useSaveSortedReportIDs(type, sortedData) and pushes the now-shorter list into the sortedReportIDs context — the current report is no longer in it.

The render side cannot recover because the outer mount gate in MoneyRequestReportNavigation keys off the snapshot, which is empty for to-do searches. useSearchPageSetup never fires search() (and therefore never writes ${SNAPSHOT}${hash}) when shouldUseLiveData is true: if (!queryJSON || hash === undefined || shouldUseLiveData || isOffline) return;. So snapshotGuard resolves to {hasMultiple: false, includesReport: false}, making isLiveGuardSatisfied false. The existing lastValidReports / shouldKeepMounted caching was added to survive a report leaving the list, but it can't help here because the gate it depends on reads the snapshot, not the live sortedReportIDs:

App/src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx

Lines 235 to 244 in ec76752

	const isLiveGuardSatisfied = isExpenseReportSearch && snapshotGuard.hasMultiple && snapshotGuard.includesReport;
	// Once the live snapshot has satisfied the guard during this mount, keep the inner component
	// mounted even if the guard later flips false (e.g. the current report is removed from the
	// snapshot after approving it). The inner component falls back to a cached list so the
	// carousel stays visible for continued navigation.
	const [shouldKeepMounted, setShouldKeepMounted] = useState(false);
	if (isLiveGuardSatisfied && !shouldKeepMounted) {
	setShouldKeepMounted(true);
	}

isLiveGuardSatisfied is effectively always false for Drafts/Needs approval/Ready to pay (empty snapshot), so shouldKeepMounted only ever latches true for the rare render where the snapshot happens to be warm. The moment the live DERIVED.TODOS recompute drops the report, there is nothing keeping the component mounted and it returns null.

I reproduced this on 9.4.9: from Spend > Drafts with two draft reports, opening one shows "1 of 2" with the prev/next arrows; tapping Submit drops the arrows while the second draft is still in the list, which is exactly the reported behavior.

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

Make the mount gate aware of the live-data path instead of relying only on the snapshot. MoneyRequestReportNavigation already reads the live list (sortedReportIDs from useSearchResultsContext() at L227), so let that satisfy the guard. Add a live guard and treat either signal as sufficient:

const liveListSatisfiesGuard = isExpenseReportSearch && liveListMatchesSearch && allReports.length > 1 && allReports.includes(reportID);
const isLiveGuardSatisfied = liveListSatisfiesGuard || (snapshotGuard.hasMultiple && snapshotGuard.includesReport && isExpenseReportSearch);

On a to-do search the guard latches true on the first render (while the report is still in reportsToSubmit), shouldKeepMounted stays true, and after Submit the existing lastValidReports fallback inside MoneyRequestReportNavigationContent keeps effectiveAllReports populated, so the arrows stay and goToNext/goToPrev keep working.

liveListMatchesSearch scopes the live branch to the current search. sortedReportIDs is global Search context set by useSaveSortedReportIDs, and it is not tied to a hash today, so a list left over from a previous expense-report search could contain reportID by coincidence. Save the producing search's hash next to the IDs (setSortedReportIDs stores queryJSON.hash alongside the list) and require it equals the report's lastSearchQuery?.queryJSON?.hash. The live branch then trusts only a list that belongs to the search the report was opened from.

This stays safe: the shouldKeepMounted latch is per-mount and resets on remount (each report-open is a fresh reportID), we still require isExpenseReportSearch and > 1 reports, and the hash check rules out a cross-search false positive. Snapshot-backed searches are untouched, since the snapshot branch of the condition does not change.

What alternative solutions did you explore? (Optional)

I considered persisting the live to-do list into ${SNAPSHOT}${hash} so the existing snapshot guard would "just work," but that duplicates the derived to-do data into Onyx, risks it going stale against DERIVED.TODOS, and widens the blast radius well past this header. Gating on the list the component already consumes is the smaller, more correct fix.

[lorretheboy]

Proposal

What is the root cause of that problem?

Submitting a report changes its stateNum/statusNum from OPEN/OPEN to SUBMITTED/SUBMITTED, so it no longer matches the DRAFTS predicate in expenseStatusActionMapping and gets filtered out of the search list (same for Needs Approval / Ready to Pay):

App/src/libs/SearchUIUtils.ts

Lines 2792 to 2804 in ec76752

	let shouldShow = true;
	const isActionLoading = isActionLoadingSet?.has(`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportItem.reportID}`);
	if (currentQueryJSON && !isActionLoading) {
	if (currentQueryJSON.type === CONST.SEARCH.DATA_TYPES.EXPENSE) {
	const status = currentQueryJSON.status;
	if (Array.isArray(status)) {
	shouldShow = status.some((expenseStatus) => {
	return isValidExpenseStatus(expenseStatus) ? expenseStatusActionMapping[expenseStatus](reportItem) : false;
	});
	} else {
	shouldShow = isValidExpenseStatus(status) ? expenseStatusActionMapping[status](reportItem) : false;

MoneyRequestReportNavigation already anticipates this and caches the last list that still contained the current report (lastValidReports), falling back to it once the live list drops the report so the arrows stay visible:

App/src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx

Lines 95 to 105 in ec76752

	const [lastValidReports, setLastValidReports] = useState<Array<string | undefined> | null>(null);
	if (liveCurrentIndex !== -1 && !isSameReportList(allReports, lastValidReports)) {
	setLastValidReports(allReports);
	}
	const effectiveAllReports = liveCurrentIndex === -1 && lastValidReports ? lastValidReports : allReports;
	const currentIndex = effectiveAllReports.indexOf(reportID);
	const allReportsCount = lastSearchQuery?.previousLengthOfResults ?? 0;
	const hideNextButton = !lastSearchQuery?.hasMoreResults && currentIndex === effectiveAllReports.length - 1;
	const hidePrevButton = currentIndex === 0;
	const shouldDisplayNavigationArrows = effectiveAllReports.length > 1 && currentIndex !== -1 && !!lastSearchQuery?.queryJSON;

The problem is where that cache lives. The outer component renders the inner content through two different branches depending on isSearchLoading — a fast path and a ...Standalone wrapper:

App/src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx

Lines 250 to 269 in ec76752

	// Fast path: use pre-computed IDs from context when available and no pagination is in flight.
	// During pagination fall back to full subscription so new pages are reflected immediately.
	if (allReports.length > 0 && !isSearchLoading) {
	return (
	<MoneyRequestReportNavigationContent
	reportID={reportID}
	shouldDisplayNarrowVersion={shouldDisplayNarrowVersion}
	allReports={allReports}
	isSearchLoading={isSearchLoading}
	lastSearchQuery={lastSearchQuery}
	/>
	);
	}
	return (
	<MoneyRequestReportNavigationStandalone
	reportID={reportID}
	shouldDisplayNarrowVersion={shouldDisplayNarrowVersion}
	/>
	);

Submitting triggers a search refresh that toggles isSearchLoading, so the rendered branch swaps. Because these are different component types at different tree positions, React unmounts one and mounts the other, throwing away its lastValidReports useState. The freshly mounted branch evaluates the list only after the report was already filtered out, so liveCurrentIndex === -1 on its very first render, the if (liveCurrentIndex !== -1 …) guard never fires, the cache is never populated, currentIndex stays -1, and shouldDisplayNavigationArrows becomes false → the arrows disappear.

In short: the cache that's meant to survive the status change is reset by the fast-path/standalone branch swap that the same status change provokes.

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

Move the cache out of the swapping children and into the stable parent. MoneyRequestReportNavigation itself never unmounts once shouldKeepMounted is set, so the lastValidReports/effectiveAllReports logic that currently lives in MoneyRequestReportNavigationContent should be lifted there:

App/src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx

Lines 95 to 100 in ec76752

	const [lastValidReports, setLastValidReports] = useState<Array<string | undefined> | null>(null);
	if (liveCurrentIndex !== -1 && !isSameReportList(allReports, lastValidReports)) {
	setLastValidReports(allReports);
	}
	const effectiveAllReports = liveCurrentIndex === -1 && lastValidReports ? lastValidReports : allReports;
	const currentIndex = effectiveAllReports.indexOf(reportID);

Compute the allReports source (fast-path context list vs. useSearchSections) in the parent, keep the "last list containing the report" cache there, and pass the resolved effectiveAllReports down to a single presentational content component. That way toggling isSearchLoading only changes which data feeds the cache — it no longer destroys it — so the cached list (still containing the just-submitted report) keeps the arrows visible.

What alternative solutions did you explore? (Optional)

Always render one MoneyRequestReportNavigationContent instance and switch only the allReports prop between the context list and the standalone list internally, instead of swapping between two component subtrees. This keeps the content instance (and its useState cache) stable across the loading transition with a smaller change.

[ahmdshrif]

Proposal

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

When viewing an attachment in the carousel, the forward/back navigation arrows disappear after a report is submitted, leaving the user unable to page between the report's attachments.

What is the root cause of that problem?

The carousel's attachment list is re-derived from reportActions on every change, and submitting a report mutates those actions:

App/src/components/Attachments/AttachmentCarousel/index.tsx

Lines 53 to 100 in ec76752

	useEffect(() => {
	const parentReportAction = report.parentReportActionID && parentReportActions ? parentReportActions[report.parentReportActionID] : undefined;
	let newAttachments: Attachment[] = [];
	if (type === CONST.ATTACHMENT_TYPE.NOTE && accountID) {
	newAttachments = extractAttachments(CONST.ATTACHMENT_TYPE.NOTE, {privateNotes: report.privateNotes, accountID, report, isReportArchived});
	} else if (type === CONST.ATTACHMENT_TYPE.ONBOARDING) {
	newAttachments = extractAttachments(CONST.ATTACHMENT_TYPE.ONBOARDING, {parentReportAction, reportActions: reportActions ?? undefined, report, isReportArchived});
	} else {
	newAttachments = extractAttachments(CONST.ATTACHMENT_TYPE.REPORT, {parentReportAction, reportActions: reportActions ?? undefined, report, isReportArchived});
	}
	if (deepEqual(attachments, newAttachments)) {
	if (attachments.length === 0) {
	setPage(-1);
	setDownloadButtonVisibility?.(false);
	}
	return;
	}
	let newIndex = newAttachments.findIndex(compareImage);
	const index = attachments.findIndex(compareImage);
	// If newAttachments includes an attachment with the same index, update newIndex to that index.
	// Previously, uploading an attachment offline would dismiss the modal when the image was previewed and the connection was restored.
	// Now, instead of dismissing the modal, we replace it with the new attachment that has the same index.
	if (newIndex === -1 && index !== -1 && newAttachments.at(index)) {
	newIndex = index;
	}
	// If no matching attachment with the same index, dismiss the modal
	if (newIndex === -1 && index !== -1 && attachments.at(index)) {
	Navigation.dismissModal();
	} else {
	setPage(newIndex);
	setAttachments(newAttachments);
	// Update the download button visibility in the parent modal
	if (setDownloadButtonVisibility) {
	setDownloadButtonVisibility(newIndex !== -1);
	}
	const attachment = newAttachments.at(newIndex);
	// Update the parent modal's state with the source and name from the mapped attachments
	if (newIndex !== -1 && attachment !== undefined && onNavigate) {
	onNavigate(attachment);
	}
	}
	}, [reportActions, parentReportActions, compareImage, attachments, setDownloadButtonVisibility, onNavigate, accountID, type, report, isReportArchived]);

The arrows' visibility is computed purely from the current page relative to attachments.length: the Back arrow is hidden when page === 0 and the Forward arrow when page === attachments.length - 1:

App/src/components/Attachments/AttachmentCarousel/CarouselButtons.tsx

Lines 40 to 41 in ec76752

	const isBackDisabled = page === 0;
	const isForwardDisabled = page === attachments.length - 1;

So when the submit re-keys/reorders the report actions, extractAttachments rebuilds the list and findIndex(compareImage) resolves the current attachment to index 0 of a now-shorter (often single-item) list. With isBackDisabled and isForwardDisabled both true, both arrows render null and "disappear."

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

In the useEffect that rebuilds attachments (index.tsx#L53-L100), preserve the navigable set across a report-action update instead of collapsing/re-indexing it: keep the prior attachments when the new derivation is a transient subset that still contains the current source/attachmentID, and recompute page against the stable list so the arrows continue to reflect the real number of attachments. The existing same-index fallback at lines 78-80 already handles part of this — extend it so the carousel does not shrink to a single page on submit.

// when newIndex === -1 but the current attachment still exists, retain the list
if (newIndex === -1 && index !== -1 && newAttachments.at(index)) {
    newIndex = index;
}

Regression check: confirm arrows still hide correctly at genuine list boundaries (true first/last attachment) and that deleting the last attachment still dismisses the modal.

[melvin-bot]

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

[aswin-s]

Proposal

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

When viewing a report from a filtered search list (Spend > Drafts, Needs Approval, Ready to Pay), clicking Submit triggers an optimistic status update that removes the report from the active snapshot, which causes the Forward/Back navigation arrows to disappear immediately instead of remaining visible so the user can navigate to the next report.

What is the root cause of that problem?

MoneyRequestReportNavigation renders one of two sub-components based on whether sortedReportIDs is already available in context:

1. Fast-path: MoneyRequestReportNavigationContent (with cached lastValidReports state) — used when allReports.length > 0 && !isSearchLoading
2. Fallback: MoneyRequestReportNavigationStandalone (subscribes to Onyx directly via useSearchSections) — used when the fast-path condition is false

When submitReport fires, it merges statusNum: SUBMITTED into Onyx optimistically. This triggers a snapshot refresh which momentarily sets search.isLoading = true. During that loading window, isSearchLoading flips to true, so the fast-path condition (allReports.length > 0 && !isSearchLoading) becomes false, and the component switches from the Content variant to the Standalone variant.

The Standalone variant mounts a fresh MoneyRequestReportNavigationContent with lastValidReports = null. Meanwhile, useSearchSections() in the Standalone path reads the refreshed snapshot whose data no longer contains the submitted report (it no longer matches "Drafts"). So allReports is empty, liveCurrentIndex === -1, effectiveAllReports falls back to lastValidReports which is null → falls through to allReports (empty), and shouldDisplayNavigationArrows becomes false → the component returns null.

The bug is on this condition in MoneyRequestReportNavigation:

App/src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx

Lines 251 to 261 in ec76752

	// During pagination fall back to full subscription so new pages are reflected immediately.
	if (allReports.length > 0 && !isSearchLoading) {
	return (
	<MoneyRequestReportNavigationContent
	reportID={reportID}
	shouldDisplayNarrowVersion={shouldDisplayNarrowVersion}
	allReports={allReports}
	isSearchLoading={isSearchLoading}
	lastSearchQuery={lastSearchQuery}
	/>
	);

The isSearchLoading flag used in the fast-path guard causes a component-type switch (Content → Standalone) at exactly the wrong moment — when submit fires a loading state — discarding the lastValidReports cache that was keeping the arrows visible.

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

The isSearchLoading guard should be removed from the fast-path condition in MoneyRequestReportNavigation. The fast-path should be used whenever allReports from context is non-empty, regardless of loading state. The MoneyRequestReportNavigationContent already handles ongoing pagination correctly via the lastValidReports cache (it only updates lastValidReports when liveCurrentIndex !== -1, so a stale cached list is preserved during refresh). The loading state is only relevant for fetching additional pages, not for deciding which component variant to mount.

Change the condition from:

if (allReports.length > 0 && !isSearchLoading) {

to:

if (allReports.length > 0) {

This keeps the fast-path (and its lastValidReports cache) active throughout the submit flow, so even when liveCurrentIndex temporarily becomes -1 after the snapshot refresh, effectiveAllReports falls back to lastValidReports (which still contains the submitted report), currentIndex resolves correctly, and shouldDisplayNavigationArrows stays true.

The isSearchLoading prop can still be passed into MoneyRequestReportNavigationContent for the pagination trigger inside goToNextReport — that usage is correct and unaffected. The original comment at lines 253–254 says "During pagination fall back to full subscription so new pages are reflected immediately," implying the Standalone path (which uses useSearchSections, a full Onyx subscription) was the intended pagination path. After the fix, MoneyRequestReportNavigationContent reads sortedReportIDs from useSearchResultsContext, which is updated whenever the search snapshot refreshes — including when goToNextReport triggers a new page fetch. So paginated reports remain visible in the carousel with no regression.

App/src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx

Lines 96 to 104 in ec76752

	if (liveCurrentIndex !== -1 && !isSameReportList(allReports, lastValidReports)) {
	setLastValidReports(allReports);
	}
	const effectiveAllReports = liveCurrentIndex === -1 && lastValidReports ? lastValidReports : allReports;
	const currentIndex = effectiveAllReports.indexOf(reportID);
	const allReportsCount = lastSearchQuery?.previousLengthOfResults ?? 0;
	const hideNextButton = !lastSearchQuery?.hasMoreResults && currentIndex === effectiveAllReports.length - 1;
	const hidePrevButton = currentIndex === 0;

This is the lastValidReports cache in MoneyRequestReportNavigationContent that already correctly handles the case where the report drops out of the live snapshot — it was designed for exactly this scenario (the comment on line 88 says "e.g. after approving from Spend > Needs Approval"). The fix simply ensures the component instance that owns this cache is not discarded during a transient loading state.

App/src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx

Lines 251 to 270 in ec76752

	// During pagination fall back to full subscription so new pages are reflected immediately.
	if (allReports.length > 0 && !isSearchLoading) {
	return (
	<MoneyRequestReportNavigationContent
	reportID={reportID}
	shouldDisplayNarrowVersion={shouldDisplayNarrowVersion}
	allReports={allReports}
	isSearchLoading={isSearchLoading}
	lastSearchQuery={lastSearchQuery}
	/>
	);
	}
	return (
	<MoneyRequestReportNavigationStandalone
	reportID={reportID}
	shouldDisplayNarrowVersion={shouldDisplayNarrowVersion}
	/>
	);
	}

What alternative solutions did you explore? (Optional)

Lift lastValidReports to the outer MoneyRequestReportNavigation component: Instead of caching it only in MoneyRequestReportNavigationContent, cache it at the outer level and pass it as a prop to both variants. This would survive the Content→Standalone switch. However, this is more invasive than necessary since the simpler fix (removing isSearchLoading from the fast-path guard) already prevents the switch from happening.

Debounce the isSearchLoading flag: Delay the switch to Standalone by debouncing isSearchLoading. This avoids the flicker but adds complexity and doesn't address the underlying issue that the component should not switch variants during a transient loading state.

[melvin-bot]

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

[github-actions]

⚠️ @lorretheboy Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).