[$250] Reports/Expense page isn’t updating for newly created expenses

[m-natarajan]

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

---

Version Number: 9.3.59-3
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): #Expensify Bugs

Action Performed:

1. Log in, switch to a copilot account
2. In the copilot account, use the receipt FAB to create an expense
3. Post creation, you are taken to the Reports page

Expected Result:

You see the scanning receipt and the row highlighted

Actual Result:

Receipt scanning displayed only after navigating back after going to different section

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

ScreenRecording_04-15-2026.13-57-05_1.MP4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Ollyws

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044482523178578015
• Upwork Job ID: 2044482523178578015
• Last Price Increase: 2026-04-15

[abbasifaizan70]

Proposal

What is the root cause of that problem?

The deferred create-expense write is intentionally blocking Search refreshes, but when the Search row skeleton is shown first, we never flush that deferred write at skeleton layout time. That leaves Search on stale data (no scanning state/highlight) until a later navigation cycle finally triggers a flush.

App/src/components/Search/index.tsx

Lines 657 to 663 in 37201cf

	// When mounting after the pre-insert fast path, the deferred write hasn't
	// been flushed yet. Triggering a search now would race with the CREATE
	// API call and return stale results that overwrite the optimistic row.
	// Skip this call; the optimistic data from flushDeferredWrite will populate
	// the list, and the next user-driven search will refresh from the server.
	if (hasPendingWriteOnMountRef.current && hasDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH)) {
	return;

App/src/components/Search/index.tsx

Lines 472 to 473 in 37201cf

	const [skeletonWasDisplayed, setSkeletonWasDisplayed] = useState(false);
	const onSkeletonLayout = useCallback(() => setSkeletonWasDisplayed(true), []);

App/src/components/Search/index.tsx

Lines 1402 to 1408 in 37201cf

	const onLayout = useCallback(() => {
	hasHadFirstLayout.current = true;
	onDestinationVisible?.(isSearchResultsEmptyRef.current, 'layout');
	endSpanWithAttributes(CONST.TELEMETRY.SPAN_NAVIGATE_TO_REPORTS, {[CONST.TELEMETRY.ATTRIBUTE_IS_WARM]: true});
	handleSelectionListScroll(stableSortedData, searchListRef.current);
	flushDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH);
	onContentReady?.();

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

1. App/src/components/Search/index.tsx

   Lines 472 to 473 in 37201cf

   	const [skeletonWasDisplayed, setSkeletonWasDisplayed] = useState(false);
   	const onSkeletonLayout = useCallback(() => setSkeletonWasDisplayed(true), []);

const onSkeletonLayout = useCallback(() => {
    setSkeletonWasDisplayed(true);
    flushDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH);
}, []);

[MelvinBot]

Proposal

What is the root cause of that problem?

When creating an expense from the global FAB, the app uses a deferred write mechanism: it pre-inserts the Search page under the RHP, then defers the API.write() call until the Search component lays out. The optimistic transaction data is applied to ONYXKEYS.COLLECTION.TRANSACTION (not to the search snapshot), and the app relies on useSearchHighlightAndScroll to detect the new transaction and trigger a server search that refreshes the snapshot.

The bug is a race condition between two search calls:

1. useSearchPageSetup (at src/hooks/useSearchPageSetup.ts:54-55) fires search() with skipWaitForWrites=true at the page level before the deferred write flushes. This returns stale server results (the expense hasn't been created server-side yet).

2. useSearchHighlightAndScroll (at src/hooks/useSearchHighlightAndScroll.ts:137) fires a re-search via InteractionManager.runAfterInteractions() after detecting the new optimistic transaction. On iOS, this callback is delayed until all native animations (modal dismiss + navigation transitions) complete.

During that delay, the stale response from call #1 populates the snapshot — and the new expense isn't in it. The cachedOptimisticItemRef mechanism (src/components/Search/index.tsx:1274) can only cache the item once it appears in sortedData, but since the snapshot never included it, the cache stays empty.

Why copilot specifically amplifies this: After a delegate switch, Onyx.clear() (src/libs/actions/Delegate.ts:200) wipes all cached search snapshots. This guarantees isSearchDataLoaded returns false, so useSearchPageSetup always fires a server search on the Reports page visit. In non-copilot mode, the snapshot may still be cached from a prior visit, which causes useSearchPageSetup to skip the search (line 51), avoiding the stale-overwrite race entirely.

When the user navigates away and back, the hasPendingSearchRef flag in useSearchHighlightAndScroll (line 102-108) triggers a fresh search on re-focus, and by then the server has processed the expense creation — so results now include it.

Supporting evidence

• Deferred write registration: src/libs/actions/IOU/TrackExpense.ts:1827-1828 (REQUEST_MONEY path), src/libs/actions/IOU/index.ts:3531-3537 (distance request)
• Deferred write flush on layout: src/components/Search/index.tsx:1407
• Search skip when deferred write pending on mount: src/components/Search/index.tsx:662
• useSearchPageSetup fires with skipWaitForWrites: src/hooks/useSearchPageSetup.ts:54-55
• InteractionManager.runAfterInteractions delays re-search: src/hooks/useSearchHighlightAndScroll.ts:137
• Delegate switch clears Onyx: src/libs/actions/Delegate.ts:200-205
• Optimistic item tracking relies on sortedData which derives from snapshot: src/components/Search/index.tsx:1274

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

The fix should ensure the re-search triggered by useSearchHighlightAndScroll after a deferred write flush isn't delayed behind animations. Instead of wrapping the search() call in InteractionManager.runAfterInteractions() at src/hooks/useSearchHighlightAndScroll.ts:137, it should fire the search immediately (or with minimal delay via setTimeout(0)) when hasPendingWriteOnMountRef was true, since the deferred write lifecycle already handled the animation-sensitive ordering.

Alternatively, the useSearchPageSetup hook could be made aware of the deferred write lifecycle more robustly — when a deferred write is pending, it should defer its own search until after the flush completes and the re-search from useSearchHighlightAndScroll has had a chance to fire, preventing the stale snapshot overwrite.

What alternative solutions did you explore?

An alternative would be to have the deferred write's optimistic data also write directly to the search snapshot (not just ONYXKEYS.COLLECTION.TRANSACTION), bypassing the need for a server re-search entirely. However, constructing a valid snapshot entry client-side from raw transaction + report data is complex and fragile, as the search API response format differs from individual Onyx collection entries.

---

Possibly related issues

• [Due for payment 2026-04-07] [$250] Reports - Per diem expense does not appear on Reports after creating per diem expense #86345 — Per diem expense does not appear on Reports after creating (same symptom, different expense type; per diem also uses registerDeferredWrite at src/libs/actions/IOU/PerDiem.ts:999)
• [$250] Home - Infinite loading on Reports>Expenses pg when creating expense from home QAB/FAB for first time #85698 — Infinite loading on Reports > Expenses when creating expense from FAB for first time (related to the deferred write + search loading lifecycle)

---

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.

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

After creating an expense via the receipt FAB (especially on a copilot account), navigating to the Reports/Expenses page does not show the new expense or its scanning state until the user leaves and returns to the page.

What is the root cause of that problem?

The root cause is a race condition in useSearchHighlightAndScroll between the initial load guard and the hasPendingSearchRef mechanism. When a new expense is created from the global create button, two things happen in sequence: mergeTransactionIdsHighlightOnSearchRoute marks the new transactionID for highlighting in Onyx, and then navigation sends the user to the Reports > Expenses search page. On iOS, during the navigation transition, isFocused from useIsFocused() is false. When the Onyx transaction data arrives while the page is still transitioning (not yet focused), the hook's first useEffect correctly sets hasPendingSearchRef.current = true and returns. However, when isFocused flips to true and the effect re-runs, the dependency change is isFocused alone — but at line 92 the guard if ((previousTransactionIDsLocal.length === 0 && previousReportActionsIDs.length === 0) || searchTriggeredRef.current) fires: previousTransactions (from usePrevious) is still null/empty on the very first render cycle when the page mounts fresh from navigation, so the guard exits early before reaching the hasPendingSearchRef.current check at line 102. The pending search is therefore never dispatched, and the search results (and highlight) never update.

App/src/hooks/useSearchHighlightAndScroll.ts

Lines 89 to 108 in 37201cf

	// Only proceed if we have previous data to compare against
	// This prevents triggering on initial data load
	if ((previousTransactionIDsLocal.length === 0 && previousReportActionsIDs.length === 0) || searchTriggeredRef.current) {
	return;
	}
	const previousTransactionsIDsSet = new Set(previousTransactionIDsLocal);
	const previousReportActionsIDsSet = new Set(previousReportActionsIDs);
	const hasTransactionsIDsChange = transactionsIDs.length !== previousTransactionIDsLocal.length || transactionsIDs.some((id) => !previousTransactionsIDsSet.has(id));
	const hasReportActionsIDsChange = reportActionsIDs.some((id) => !previousReportActionsIDsSet.has(id));
	// Check if there is a change in the transactions or report actions list
	if ((!isChat && hasTransactionsIDsChange) || hasReportActionsIDsChange || hasPendingSearchRef.current) {
	// If we're not focused or offline, don't trigger search
	if (!isFocused || isOffline) {
	hasPendingSearchRef.current = true;
	return;
	}
	hasPendingSearchRef.current = false;

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

The fix is to move the hasPendingSearchRef.current check before the empty-previous-data guard. If there is a pending search that was deferred because the page was not focused, we should execute it as soon as the page becomes focused, regardless of whether previousTransactions is populated yet. This way the copilot flow — where the transaction already exists in Onyx before the page finishes its navigation transition — correctly triggers the search and shows the new expense with its highlight.

App/src/hooks/useSearchHighlightAndScroll.ts

Lines 89 to 143 in 37201cf

	// Only proceed if we have previous data to compare against
	// This prevents triggering on initial data load
	if ((previousTransactionIDsLocal.length === 0 && previousReportActionsIDs.length === 0) || searchTriggeredRef.current) {
	return;
	}
	const previousTransactionsIDsSet = new Set(previousTransactionIDsLocal);
	const previousReportActionsIDsSet = new Set(previousReportActionsIDs);
	const hasTransactionsIDsChange = transactionsIDs.length !== previousTransactionIDsLocal.length || transactionsIDs.some((id) => !previousTransactionsIDsSet.has(id));
	const hasReportActionsIDsChange = reportActionsIDs.some((id) => !previousReportActionsIDsSet.has(id));
	// Check if there is a change in the transactions or report actions list
	if ((!isChat && hasTransactionsIDsChange) || hasReportActionsIDsChange || hasPendingSearchRef.current) {
	// If we're not focused or offline, don't trigger search
	if (!isFocused || isOffline) {
	hasPendingSearchRef.current = true;
	return;
	}
	hasPendingSearchRef.current = false;
	const newIDs = isChat ? reportActionsIDs : transactionsIDs;
	let currentSearchResultIDs: string[] = [];
	if (searchResultsData) {
	currentSearchResultIDs = isChat ? extractReportActionIDsFromSearchResults(searchResultsData) : extractTransactionIDsFromSearchResults(searchResultsData);
	}
	const existingSearchResultIDsSet = new Set(currentSearchResultIDs);
	const hasAGenuinelyNewID = newIDs.some((id) => !existingSearchResultIDsSet.has(id));
	// Only skip search if there are no new items AND search results aren't empty
	// This ensures deletions that result in empty data still trigger search
	if (!hasAGenuinelyNewID && currentSearchResultIDs.length > 0) {
	const newIDsSet = new Set(newIDs);
	const hasDeletedID = currentSearchResultIDs.some((id) => !newIDsSet.has(id));
	if (!hasDeletedID) {
	return;
	}
	}
	// We only want to highlight new items if the addition of transactions or report actions triggered the search.
	// This is because, on deletion of items, the backend sometimes returns old items in place of the deleted ones.
	// We don't want to highlight these old items, even if they appear new in the current search results.
	hasNewItemsRef.current = isChat ? reportActionsIDs.length > previousReportActionsIDs.length : transactionsIDs.length > previousTransactionIDsLocal.length;
	// Set the flag indicating the search is triggered by the hook
	triggeredByHookRef.current = true;
	// Trigger the search
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	InteractionManager.runAfterInteractions(() => {
	search({queryJSON, searchKey, offset, shouldCalculateTotals, isLoading: !!searchResults?.search?.isLoading});
	});
	// Set the ref to prevent further triggers until reset
	searchTriggeredRef.current = true;
	}

     // Only proceed if we have previous data to compare against
     // This prevents triggering on initial data load
-    if ((previousTransactionIDsLocal.length === 0 && previousReportActionsIDs.length === 0) || searchTriggeredRef.current) {
-        return;
+    if (searchTriggeredRef.current) {
+        return;
     }

+    // If a search was deferred while the page was not focused, execute it now that we are focused
+    if (hasPendingSearchRef.current) {
+        if (!isFocused || isOffline) {
+            return;
+        }
+        hasPendingSearchRef.current = false;
+        triggeredByHookRef.current = true;
+        hasNewItemsRef.current = true;
+        searchTriggeredRef.current = true;
+        // eslint-disable-next-line @typescript-eslint/no-deprecated
+        InteractionManager.runAfterInteractions(() => {
+            search({queryJSON, searchKey, offset, shouldCalculateTotals, isLoading: !!searchResults?.search?.isLoading});
+        });
+        return;
+    }
+
+    if (previousTransactionIDsLocal.length === 0 && previousReportActionsIDs.length === 0) {
+        return;
+    }
+
     const previousTransactionsIDsSet = new Set(previousTransactionIDsLocal);

This separates the two guards that were previously conflated. The "no previous data" guard still prevents spurious searches on initial load when no transaction was just created. But when hasPendingSearchRef.current is true (set before navigation completed), the pending search fires immediately on focus without waiting for a transactions diff, ensuring the new expense appears and is highlighted as soon as the page is ready.

What alternative solutions did you explore? (Optional)

An alternative would be to trigger a search directly inside handleNavigateAfterExpenseCreate after navigation completes, rather than relying on the hook's diff logic. That approach would work but would duplicate search-triggering logic that already lives in the hook and would not benefit from the hook's deduplication and highlight state management.

[twilight2294]

Proposal

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

When acting as a copilot (delegate) and creating a new expense, the Reports/Expense page doesn't show the newly created expense until you navigate away and back.

What is the root cause of that problem?

Two independent Onyx subscriptions in IOU have a hidden data dependency: Callback A sets deprecatedUserAccountID from SESSION, and Callback B uses that variable to look up deprecatedCurrentUserPersonalDetails from PERSONAL_DETAILS_LIST. During delegate switching, Onyx.clear() in Delegate wipes PERSONAL_DETAILS_LIST (not preserved), then openApp() repopulates both keys. If Callback B fires before Callback A, it reads the stale deprecatedUserAccountID (original user's ID), finds no match in the delegator's personal details, and deprecatedCurrentUserPersonalDetails becomes permanently undefined.

This blocks the optimistic search snapshot in getSearchOnyxUpdate() at line 4520: the fromAccountID != null gate fails because deprecatedCurrentUserPersonalDetails?.accountID is undefined, so the entire optimistic snapshot is skipped and the Reports page stays stale.

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

In IOU, derive fromAccountID from the reliable deprecatedUserAccountID (set directly from SESSION, which is preserved through Onyx.clear) instead of the race-prone deprecatedCurrentUserPersonalDetails?.accountID:

// Line 4518 — replace:
const fromAccountID = deprecatedCurrentUserPersonalDetails?.accountID;
// with:
const fromAccountID = deprecatedUserAccountID !== -1 ? deprecatedUserAccountID : undefined;

Then use allPersonalDetails (already available at line 397) for the display fields in the snapshot data around lines 4553–4558:

const fromPersonalDetails = allPersonalDetails[fromAccountID ?? -1];
// Then use fromPersonalDetails.avatar, .displayName, .login in the snapshot

What alternative solutions did you explore?

This differs from both existing proposals in root cause and fix location. MelvinBot's proposal targets useSearchHighlightAndScroll timing (InteractionManager.runAfterInteractions delay), and abbasifaizan70's targets deferred write flushing in the Search component. Both assume the optimistic data is correctly prepared but delivered too late. The actual problem is upstream: the optimistic search snapshot is never built at all because the Onyx callback race leaves fromAccountID as undefined. Fixing search timing won't help if the optimistic data was never constructed. This fix addresses why the data is missing in the first place, at the exact point of failure.

[wildan-m]

Proposal

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

When an expense is created from the global create FAB on the inbox tab, the post-creation Reports/Expense page does not show the newly-scanned receipt (or its highlight) until the user navigates away and back. The repro in the issue happens inside a copilot session on iOS App, but the underlying mechanism is not copilot-specific — the common factor is that the user is not already on the Search tab when the create flow fires.

What is the root cause of that problem?

The money-request build flow computes an optimistic Search snapshot update so the new expense appears immediately in cached Reports data. That update is produced by getSearchOnyxUpdate, which reads the currently displayed search query via getCurrentSearchQueryJSON() and writes the optimistic entry into the snapshot keyed by that current query's hash:

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

Lines 3728 to 3800 in 37201cf

	function getSearchOnyxUpdate({
	participant,
	transaction,
	iouReport,
	iouAction,
	policy,
	transactionThreadReportID,
	isFromOneTransactionReport,
	isInvoice,
	}: GetSearchOnyxUpdateParams): OnyxData<typeof ONYXKEYS.COLLECTION.SNAPSHOT> | undefined {
	const toAccountID = participant?.accountID;
	const fromAccountID = deprecatedCurrentUserPersonalDetails?.accountID;
	const currentSearchQueryJSON = getCurrentSearchQueryJSON();
	if (currentSearchQueryJSON && toAccountID != null && fromAccountID != null) {
	if (shouldOptimisticallyUpdateSearch(currentSearchQueryJSON, iouReport, isInvoice, transaction)) {
	const isOptimisticToAccountData = isOptimisticPersonalDetail(toAccountID);
	const successData = [];
	if (isOptimisticToAccountData) {
	// The optimistic personal detail is removed on the API's success data but we can't change the managerID of the transaction in the snapshot.
	// So we need to add the optimistic personal detail back to the snapshot in success data to prevent the flickering.
	// After that, it will be cleared via Search API.
	// See https://github.com/Expensify/App/issues/61310 for more information.
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.SNAPSHOT}${currentSearchQueryJSON.hash}` as const,
	value: {
	data: {
	[ONYXKEYS.PERSONAL_DETAILS_LIST]: {
	[toAccountID]: {
	accountID: toAccountID,
	displayName: participant?.displayName,
	login: participant?.login,
	},
	},
	},
	},
	});
	}
	const snapshotData = {
	[ONYXKEYS.PERSONAL_DETAILS_LIST]: {
	[toAccountID]: {
	accountID: toAccountID,
	displayName: participant?.displayName,
	login: participant?.login,
	},
	[fromAccountID]: {
	accountID: fromAccountID,
	avatar: deprecatedCurrentUserPersonalDetails?.avatar,
	displayName: deprecatedCurrentUserPersonalDetails?.displayName,
	login: deprecatedCurrentUserPersonalDetails?.login,
	},
	},
	[`${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`]: {
	accountID: fromAccountID,
	managerID: toAccountID,
	...(transactionThreadReportID && {transactionThreadReportID}),
	...(isFromOneTransactionReport && {isFromOneTransactionReport}),
	...transaction,
	},
	...(policy && {[`${ONYXKEYS.COLLECTION.POLICY}${policy.id}`]: policy}),
	...(iouReport && {[`${ONYXKEYS.COLLECTION.REPORT}${iouReport.reportID}`]: iouReport}),
	...(iouReport && iouAction && {[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport.reportID}`]: {[iouAction.reportActionID]: iouAction}}),
	};
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.SNAPSHOT>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.SNAPSHOT}${currentSearchQueryJSON.hash}` as const,
	value: {
	// @ts-expect-error - will be solved in https://github.com/Expensify/App/issues/73830
	data: snapshotData,
	},

getCurrentSearchQueryJSON() inspects the navigation root for a SEARCH_FULLSCREEN_NAVIGATOR entry. When the user is on the inbox tab (or any non-Search fullscreen tab) there is no such navigator route yet, so the function returns undefined:

App/src/libs/SearchQueryUtils.ts

Lines 1786 to 1810 in 37201cf

	function getCurrentSearchQueryJSON() {
	const rootState = navigationRef.getRootState();
	const lastSearchNavigator = rootState?.routes?.findLast((route) => route.name === NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR);
	let lastSearchNavigatorState = lastSearchNavigator?.state;
	if (!lastSearchNavigatorState) {
	lastSearchNavigatorState = lastSearchNavigator && lastSearchNavigator.key ? getPreservedNavigatorState(lastSearchNavigator?.key) : undefined;
	}
	if (!lastSearchNavigatorState) {
	return;
	}
	const lastSearchRoute = lastSearchNavigatorState.routes.findLast((route) => route.name === SCREENS.SEARCH.ROOT);
	if (!lastSearchRoute || !lastSearchRoute.params) {
	return;
	}
	const {q: searchParams, rawQuery} = lastSearchRoute.params as SearchFullscreenNavigatorParamList[typeof SCREENS.SEARCH.ROOT];
	const queryJSON = buildSearchQueryJSON(searchParams, rawQuery);
	if (!queryJSON) {
	return;
	}
	return queryJSON;
	}

With currentSearchQueryJSON undefined, the outer guard if (currentSearchQueryJSON && toAccountID != null && fromAccountID != null) fails and the whole snapshot update is skipped. The call site in buildOnyxDataForMoneyRequest then has nothing to push onto optimisticData:

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

Lines 2026 to 2043 in 37201cf

	const searchUpdate = getSearchOnyxUpdate({
	transaction,
	participant,
	iouReport,
	iouAction,
	policy,
	transactionThreadReportID: transactionThreadReport?.reportID,
	isFromOneTransactionReport: isOneTransactionReport(iou.report),
	});
	if (searchUpdate) {
	if (searchUpdate.optimisticData) {
	onyxData.optimisticData?.push(...searchUpdate.optimisticData);
	}
	if (searchUpdate.successData) {
	onyxData.successData?.push(...searchUpdate.successData);
	}
	}

Meanwhile, post-creation navigation always routes the user to the canned type:EXPENSE search (or type:INVOICE when invoicing). The destination query string is produced by buildCannedSearchQuery({type}) and applied via Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: queryString}), {forceReplace: true}):

App/src/libs/Navigation/helpers/navigateAfterExpenseCreate.ts

Lines 40 to 72 in 37201cf

	const type = isInvoice ? CONST.SEARCH.DATA_TYPES.INVOICE : CONST.SEARCH.DATA_TYPES.EXPENSE;
	// When already on Search ROOT with the same type (expense vs invoice), we navigate to the same screen (no-op or refresh); record as dismiss_modal_only.
	// When on another Search sub-tab (e.g. Chats), or on Search with a different type (e.g. on Invoice, submitting expense), record as navigate_to_search.
	const rootState = navigationRef.getRootState();
	const searchNavigatorRoute = rootState?.routes?.findLast((route) => route.name === NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR);
	const lastSearchRoute = searchNavigatorRoute?.state?.routes?.at(-1);
	const alreadyOnSearchRoot = isSearchTopmostFullScreenRoute() && lastSearchRoute?.name === SCREENS.SEARCH.ROOT;
	const currentSearchQueryJSON = alreadyOnSearchRoot ? getCurrentSearchQueryJSON() : undefined;
	const isSameSearchType = currentSearchQueryJSON?.type === type;
	setPendingSubmitFollowUpAction(
	alreadyOnSearchRoot && isSameSearchType ? CONST.TELEMETRY.SUBMIT_FOLLOW_UP_ACTION.DISMISS_MODAL_ONLY : CONST.TELEMETRY.SUBMIT_FOLLOW_UP_ACTION.NAVIGATE_TO_SEARCH,
	);
	const queryString = buildCannedSearchQuery({type});
	const navigateToSearch = () => {
	// On the fast path, onConfirm already cleared the flag and dismissed the modal,
	// so this branch is only reached on the slow path (user submitted before the
	// 300ms pre-insert timer fired).
	if (getIsNarrowLayout() && Navigation.getIsFullscreenPreInsertedUnderRHP()) {
	Navigation.clearFullscreenPreInsertedFlag();
	Navigation.dismissModal();
	} else if (getIsNarrowLayout()) {
	const isRHPStillOnTop = navigationRef.getRootState()?.routes?.at(-1)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;
	if (!alreadyOnSearchRoot || !isSameSearchType || isRHPStillOnTop) {
	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: queryString}), {forceReplace: true});
	} else {
	Log.info('[IOU] navigateToSearch: already on matching Search root with RHP dismissed — no-op');
	}
	} else {
	Navigation.revealRouteBeforeDismissingModal(ROUTES.SEARCH_ROOT.getRoute({query: queryString}));
	}
	};

That canned query resolves to a specific deterministic snapshot hash. Because no optimistic write ever targeted that hash, the destination Reports page renders against a stale cached snapshot that does not contain the new row. The snapshot is only corrected later, when a server re-search completes and overwrites the cache — which happens via the re-focus path in useSearchHighlightAndScroll, explaining why navigating away and back makes the row appear.

The fundamental mismatch: the optimistic snapshot write is location-bound (it targets whatever search the user happens to be on), but the post-creation navigation is destination-bound (it always lands on the canned type:EXPENSE/type:INVOICE search). When those two diverge — which they always do on the inbox-to-reports flow — the destination never gets populated.

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

Adopt the destination-aware optimistic snapshot pattern that Task.ts already uses for new tasks and Report.ts already uses for new chat rooms. Both of those flows call buildOptimisticSnapshotData(type, data) to write the optimistic update into the canned query hash directly, so the new item appears on the destination page regardless of where the user was when the create fired:

App/src/libs/SearchQueryUtils.ts

Lines 1921 to 1938 in 37201cf

	/**
	* Builds an optimistic Snapshot update to ensure offline data for Tasks and Chat messages appears in Search.
	*/
	function buildOptimisticSnapshotData(type: SearchDataTypes, data: Record<string, unknown>): OnyxUpdate<typeof ONYXKEYS.COLLECTION.SNAPSHOT> | undefined {
	const searchQuery = buildCannedSearchQuery({type});
	const searchQueryJSON = buildSearchQueryJSON(searchQuery);
	if (!searchQueryJSON) {
	return;
	}
	return {
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.SNAPSHOT}${searchQueryJSON.hash}`,
	value: {
	// @ts-expect-error - will be solved in https://github.com/Expensify/App/issues/73830
	data,
	},
	};
	}

App/src/libs/actions/Task.ts

Lines 273 to 296 in 37201cf

	const searchDataTypes = [CONST.SEARCH.DATA_TYPES.CHAT, CONST.SEARCH.DATA_TYPES.TASK];
	const snapshotDataToStore = {
	[`${ONYXKEYS.COLLECTION.REPORT}${optimisticTaskReport.reportID}`]: {
	...completeOptimisticTaskReport,
	accountID: currentUserAccountID,
	},
	[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${optimisticTaskReport.reportID}`]: {
	[optimisticTaskCreatedAction.reportActionID]: optimisticTaskCreatedAction as OnyxTypes.ReportAction,
	},
	[`${ONYXKEYS.COLLECTION.REPORT}${parentReportID}`]: optimisticParentReport,
	[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID}`]: {
	[optimisticAddCommentReport.reportAction.reportActionID]: optimisticAddCommentReport.reportAction as OnyxTypes.ReportAction,
	},
	[ONYXKEYS.PERSONAL_DETAILS_LIST]: personalDetailsList,
	};
	// We push the optimistic task data into chat and task snapshot hashes so it appears immediately in "Reports > Chats" and "Reports > Task" while offline.
	for (const type of searchDataTypes) {
	const optimisticSnapshotUpdate = buildOptimisticSnapshotData(type, snapshotDataToStore);
	if (optimisticSnapshotUpdate) {
	optimisticData.push(optimisticSnapshotUpdate);
	}
	}

In the expense creation path, the shape of snapshotData (personal details, transaction, policy, report, report actions) is already built inside getSearchOnyxUpdate using the same keys that buildOptimisticSnapshotData expects. The fix is additive: while computing the optimistic data in buildOnyxDataForMoneyRequest, also emit a snapshot update that targets the canned destination hash by calling buildOptimisticSnapshotData(CONST.SEARCH.DATA_TYPES.EXPENSE, snapshotData) (or INVOICE on invoice flows) and pushing that update onto optimisticData alongside the existing current-search update.

This requires threading the isFromGlobalCreate and isInvoice flags through BuildOnyxDataForMoneyRequestParams so that the canned-hash write only fires on flows that actually navigate to Reports — not on in-report split submissions where the current-search update is already the right target. The existing current-search update stays in place unchanged, so users who were already on a custom Search view still see their filtered snapshot updated.

The fix is deterministic (no extra network round-trip, no race with InteractionManager, no dependence on isFocused transitions), it reuses an already-validated pattern from Task/Report, and it produces no new data shapes — the snapshot payload is identical to the one the current code already builds.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87999-global-create-expense-snapshot?expand=1

What alternative solutions did you explore? (Optional)

One alternative is to always refresh the canned Reports snapshot on page mount by removing the isSearchDataLoaded short-circuit in useSearchPageSetup, so a server search fires on every visit regardless of cache state. This would eventually show the new row, but it trades an O(1) local Onyx merge for an O(network) server request on every visit to Reports/Expense, degrading perceived performance for users who revisit the tab frequently and pushing the correctness fix onto the server roundtrip latency budget.

Another alternative is to rewrite getSearchOnyxUpdate itself so that its snapshot hash is always computed from the destination type (derived from isFromGlobalCreate + isInvoice) rather than from getCurrentSearchQueryJSON(). This works but changes the semantics of an existing function that other in-report submission flows still depend on — those flows legitimately want the current search updated, not the canned one. The additive approach preserves that existing behavior and only layers the canned-hash write on top when the flow is actually about to navigate to the canned page.

[wildan-m]

Proposal updated — added compare branch with implementation.