[$250] Web - Scan Receipt -Not here page RHP appears after close the review second reciept scanning

[jponikarchuk]

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.3.62-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-22315/folder/13176933/41237704/1366323870?sort=%2Bidentifier
Email or phone of affected tester (no customers): applausetester+vq@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Chat Report View

Action Performed:

Precondition: User is logged in with Expensify account and has a Workspace chat with a draft report and a scan expense in it

1. Open the NewDot app
2. Click on the FAB - Quick action - Create expense - Scan
3. Upload a receipt
4. When it scans, quickly click on the expense to open the details
5. Click on the Receipt to open the receipt review
6. Wait until the scan finishes in 30s or 1 min, then close the receipt review

Expected Result:

The scan expense with a receipt appears

Actual Result:

Not here page on the wide RHP appears

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054388125879553751
• Upwork Job ID: 2054388125879553751
• Last Price Increase: 2026-05-27

[MelvinBot]

Proposal

What is the root cause of that problem?

When a scan expense is created, an optimistic expense report is created with a temporary ID. If the server returns a preexistingReportID (indicating a matching report already exists), replaceOptimisticReportWithActualReport nulls out the optimistic report and its parent REPORT_PREVIEW action:

if (isMoneyRequestReport(report) && parentReportID && parentReportActionID) {
    Onyx.merge(..., { [parentReportActionID]: null });
    Onyx.merge(...report, null);
    return; // ← exits early, skipping the navigation redirect logic below
}

The problem is this early return skips the navigation redirect logic on lines 143-184 that would normally update the route params to point to the preexisting report.

There's a second layer: useDismissOnMoneyRequestReportRemoval is a safety net that dismisses the modal when the report disappears — but it only fires when the page isFocused. When the receipt review modal is on top, SearchMoneyRequestReportPage is not focused, so dismissal is skipped. When focus returns (user closes receipt modal), prevReport is already null, so the hook doesn't fire again.

The result: the RHP route still points to the deleted optimistic report ID → SearchMoneyRequestReportPage evaluates shouldShowAccessErrorPage as true → "Not here" page.

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

The money request report branch in replaceOptimisticReportWithActualReport (lines 67-73) should not return early. Instead, it should proceed to the navigation redirect logic (lines 143-184) so the route params get updated to the preexistingReportID, just like DMs and transaction threads already do. Specifically, after nulling the optimistic report and its parent action, the function should continue to check isOptimisticReportFocused / isOptimisticReportInBackground and call Navigation.setParams({reportID: preexistingReportID}) to redirect to the correct report.

What alternative solutions did you explore? (Optional)

An alternative would be to fix useDismissOnMoneyRequestReportRemoval to handle the case where the report was deleted while the page was not focused (e.g., by checking for a stale/null report when focus returns). However, this would only dismiss the modal instead of redirecting to the correct preexisting report, which is a worse UX. Fixing the navigation redirect in replaceOptimisticReportWithActualReport is the more complete solution since it preserves the user's navigation context.

Related issues

• [Due for payment 2026-05-29] Expense - Not here page opens when paying with business account after deleting other report #88939 — similar "Not here" page pattern when underlying report data changes
• [$250] Clicking "View Details" on an expense/report shows the "Hmm... it's not here" page #89724 — "Not here" page when clicking "View Details" on an expense

---

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 - @rojiphil (External)

[melvin-bot]

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

[wildan-m]

Proposal

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

On Web (wide layout), after creating a Scan expense via the FAB Quick Action and clicking the still-scanning expense in chat to open the receipt review, the wide RHP shows the "Not here" page once the user closes the review (after the scan finishes). Expected: the transaction details RHP for the now-scanned expense should be shown.

What is the root cause of that problem?

The Quick Action scan flow intentionally does not pre-create a transaction thread report at submission time. The IOU action that lands in the chat for a scan-pending expense therefore has no childReportID. This is hard-coded in the scan hook:

App/src/pages/iou/request/step/IOURequestStepScan/hooks/useReceiptScan.ts

Lines 131 to 134 in c07f8e4

	backToReport,
	shouldSkipConfirmation,
	defaultExpensePolicy,
	shouldGenerateTransactionThreadReport: false,

When the user clicks that IOU action while the receipt is still being scanned, MoneyRequestAction.onMoneyRequestPreviewPressed falls into the "no childReportID yet" branch and creates an optimistic transaction thread T1 on the spot, then navigates the wide RHP to it:

App/src/components/ReportActionItem/MoneyRequestAction.tsx

Lines 117 to 137 in c07f8e4

	// In case the childReportID is not present it probably means the transaction thread was not created yet,
	// so we need to send the parentReportActionID and the transactionID to the route so we can call OpenReport correctly
	const transactionID = isMoneyRequestAction(action) ? getOriginalMessage(action)?.IOUTransactionID : CONST.DEFAULT_NUMBER_ID;
	if (!action?.childReportID && transactionID && action.reportActionID) {
	const transactionThreadReport = createTransactionThreadReport(introSelected, currentUserEmail ?? '', currentUserAccountID, betas, iouReport, action);
	if (shouldOpenReportInRHP) {
	Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: transactionThreadReport?.reportID, backTo: Navigation.getActiveRoute()}));
	return;
	}
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(transactionThreadReport?.reportID, undefined, undefined, Navigation.getActiveRoute()));
	return;
	}
	if (shouldOpenReportInRHP) {
	Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: action?.childReportID, backTo: Navigation.getActiveRoute()}));
	return;
	}
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(action?.childReportID, undefined, undefined, Navigation.getActiveRoute()));
	};

The optimistic thread T1 is built with parentReportActionID pointing at the (still optimistic) IOU action and parentReportID pointing at the IOU/expense report:

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

Lines 1907 to 1969 in c07f8e4

	function createTransactionThreadReport(
	introSelected: OnyxEntry<IntroSelected>,
	currentUserLogin: string,
	currentUserAccountID: number,
	betas: OnyxEntry<Beta[]>,
	iouReport?: OnyxEntry<Report>,
	iouReportAction?: OnyxEntry<ReportAction>,
	transaction?: Transaction,
	transactionViolations?: TransactionViolations,
	// TODO: personalDetails should be a required field in follow-up PRs https://github.com/Expensify/App/issues/73656
	personalDetails?: OnyxEntry<PersonalDetailsList>,
	): OptimisticChatReport | undefined {
	// Determine if we need selfDM report (for track expenses or unreported transactions)
	const isTrackExpense = !iouReport && ReportActionsUtils.isTrackExpenseAction(iouReportAction);
	const isUnreportedTransaction = transaction?.reportID === CONST.REPORT.UNREPORTED_REPORT_ID;
	const selfDMReportID = isTrackExpense || isUnreportedTransaction ? findSelfDMReportID() : undefined;
	let optimisticSelfDMReport: Report | undefined;
	let reportToUse = iouReport;
	if (selfDMReportID) {
	reportToUse = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${selfDMReportID}`];
	// selfDMReportID may be set but the report is filtered out.
	// Create an optimistic report if needed to proceed with the transaction thread.
	if (!reportToUse) {
	optimisticSelfDMReport = buildOptimisticSelfDMReport(DateUtils.getDBTime(), selfDMReportID);
	reportToUse = optimisticSelfDMReport;
	}
	}
	if (!reportToUse?.reportID) {
	Log.warn('Cannot build transaction thread report without a valid report');
	return;
	}
	// Sync fresh report data from snapshot to allReports. When navigating from search,
	// allReports may be stale and missing parentReportID/parentReportActionID, causing
	// getAllAncestorReportActionIDs() to fail when adding comments optimistically.
	if (iouReport?.reportID && reportToUse.reportID === iouReport.reportID) {
	Onyx.merge(`${ONYXKEYS.COLLECTION.REPORT}${iouReport.reportID}`, iouReport);
	}
	const optimisticTransactionThreadReportID = generateReportID();
	const optimisticTransactionThread = buildTransactionThread(iouReportAction, reportToUse, undefined, optimisticTransactionThreadReportID);
	const shouldAddPendingFields = transaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD || iouReportAction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD;
	openReport({
	reportID: optimisticTransactionThreadReportID,
	introSelected,
	participants: currentUserLogin ? [{login: currentUserLogin, accountID: currentUserAccountID}] : [],
	// TODO: allPersonalDetails fallback should be removed in follow-up PRs https://github.com/Expensify/App/issues/73656
	personalDetails: personalDetails ?? allPersonalDetails,
	newReportObject: optimisticTransactionThread,
	parentReportActionID: iouReportAction?.reportActionID,
	transaction,
	transactionViolations,
	parentReportID: selfDMReportID,
	shouldAddPendingFields,
	optimisticSelfDMReport,
	currentUserLogin,
	currentUserAccountID,
	betas,
	});
	return optimisticTransactionThread;

From the wide RHP at /r/T1, the user then opens the receipt review at /r/T1/transaction/<txID>/receipt. While the receipt review is mounted on top, SmartScan completes server-side. The completion event delivers fresh state for the IOU action and the IOU report through Pusher / OpenReport response data — and because T1 was generated client-side after the scan was already in flight, the merges that resolve the IOU action's final identity end up racing with the link T1 was holding to it. The net result is that, by the time the user closes the receipt review, T1's parentReportActionID no longer resolves to a present, visible IOU action in parentReportID's actions collection.

Closing the receipt modal calls Navigation.dismissModal():

App/src/pages/media/AttachmentModalScreen/AttachmentModalContainer/index.tsx

Lines 28 to 31 in c07f8e4

	const closeModal = useCallback(() => {
	Navigation.dismissModal();
	resetAttachmentModalAndClose();
	}, [resetAttachmentModalAndClose]);

Which pops the receipt modal screen and lands the user back on the wide RHP screen for T1. ReportNotFoundGuard wraps that screen and, because T1 is a transaction thread, runs the inner guard which shows "Not here" when the parent action is missing or has been deleted after load:

App/src/pages/inbox/ReportNotFoundGuard.tsx

Lines 100 to 162 in c07f8e4

	if (!deleteTransactionNavigateBackUrl && isReportTransactionThread(report)) {
	return <ReportNotFoundInnerGuard reportIDFromPath={routeParams?.reportID}>{children}</ReportNotFoundInnerGuard>;
	}
	return children;
	}
	type ReportNotFoundInnerGuardProps = {
	reportIDFromPath: string | undefined;
	children: ReactNode;
	};
	/**
	* Inner guard for transaction threads only. Subscribes to the expensive
	* parentReportMetadata and parentReportAction to detect deleted parent actions.
	*/
	// eslint-disable-next-line rulesdir/no-negated-variables
	function ReportNotFoundInnerGuard({reportIDFromPath, children}: ReportNotFoundInnerGuardProps) {
	const styles = useThemeStyles();
	const {shouldUseNarrowLayout} = useResponsiveLayout();
	const {isOffline} = useNetwork();
	const reportIDFromRoute = getNonEmptyStringOnyxID(reportIDFromPath);
	const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${reportIDFromRoute}`);
	const [parentReportMetadata] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_METADATA}${report?.parentReportID}`);
	const parentReportAction = useParentReportAction(report);
	const {isParentActionMissingAfterLoad, isParentActionDeleted} = getParentReportActionDeletionStatus({
	parentReportID: report?.parentReportID,
	parentReportActionID: report?.parentReportActionID,
	parentReportAction,
	parentReportMetadata,
	isOffline,
	});
	// eslint-disable-next-line rulesdir/no-negated-variables
	const shouldShowNotFoundPage = isParentActionDeleted || isParentActionMissingAfterLoad;
	useEffect(() => {
	if (!shouldShowNotFoundPage) {
	return;
	}
	Log.info('[ReportScreen] Displaying NotFound Page (deleted transaction thread)', false, {
	reportIDFromPath,
	isParentActionDeleted,
	isParentActionMissingAfterLoad,
	});
	}, [shouldShowNotFoundPage, reportIDFromPath, isParentActionDeleted, isParentActionMissingAfterLoad]);
	return (
	<FullPageNotFoundView
	shouldShow={shouldShowNotFoundPage}
	subtitleKey="notFound.noAccess"
	subtitleStyle={[styles.textSupporting]}
	shouldShowBackButton={shouldUseNarrowLayout}
	onBackButtonPress={Navigation.goBack}
	shouldShowLink={false}
	shouldDisplaySearchRouter
	>
	{children}
	</FullPageNotFoundView>
	);
	}

The trigger sequence (click while scanning → optimistic thread → wait for scan in receipt review → close) is the only path that consistently produces a transaction-thread RHP whose parent action can disappear underneath it, which is why the "Not here" page is reproducible exactly under those steps and not in the post-scan flow.

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

The fix is to avoid creating the optimistic transaction thread in the click handler when the underlying transaction's receipt is still being scanned, since that is the precise window in which T1's parent-action link is fragile. Instead, route the click to a destination that is guaranteed to remain valid across scan completion.

Specifically, in MoneyRequestAction.onMoneyRequestPreviewPressed:

App/src/components/ReportActionItem/MoneyRequestAction.tsx

Lines 104 to 137 in c07f8e4

	const onMoneyRequestPreviewPressed = () => {
	if (onPreviewPressed && action?.childReportID) {
	onPreviewPressed(action?.childReportID);
	return;
	}
	if (contextMenuRef.current?.isContextMenuOpening) {
	return;
	}
	if (isSplitBillAction) {
	Navigation.navigate(ROUTES.SPLIT_BILL_DETAILS.getRoute(chatReportID, action.reportActionID, Navigation.getReportRHPActiveRoute()));
	return;
	}
	// In case the childReportID is not present it probably means the transaction thread was not created yet,
	// so we need to send the parentReportActionID and the transactionID to the route so we can call OpenReport correctly
	const transactionID = isMoneyRequestAction(action) ? getOriginalMessage(action)?.IOUTransactionID : CONST.DEFAULT_NUMBER_ID;
	if (!action?.childReportID && transactionID && action.reportActionID) {
	const transactionThreadReport = createTransactionThreadReport(introSelected, currentUserEmail ?? '', currentUserAccountID, betas, iouReport, action);
	if (shouldOpenReportInRHP) {
	Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: transactionThreadReport?.reportID, backTo: Navigation.getActiveRoute()}));
	return;
	}
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(transactionThreadReport?.reportID, undefined, undefined, Navigation.getActiveRoute()));
	return;
	}
	if (shouldOpenReportInRHP) {
	Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: action?.childReportID, backTo: Navigation.getActiveRoute()}));
	return;
	}
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(action?.childReportID, undefined, undefined, Navigation.getActiveRoute()));
	};

Before falling into the createTransactionThreadReport branch (the !action?.childReportID && transactionID && action.reportActionID case), look up the transaction for transactionID and check isReceiptBeingScanned(transaction). If the receipt is still being scanned:

• Skip createTransactionThreadReport.
• Navigate the wide RHP to the IOU/expense report containing this action (requestReportID) instead, using the existing ROUTES.SEARCH_REPORT.getRoute({reportID: requestReportID, …}) (or ROUTES.REPORT_WITH_ID.getRoute(requestReportID, …) on narrow layouts). The IOU/expense report is created and persisted before the click happens and is unaffected by the scan-completion merges, so closing any subsequent receipt review lands the user on a real, present report — never on an orphaned thread.
• The user still sees the expense (the RHP shows the IOU report's preview list including the scanned expense). Once scan completes and action.childReportID is populated by the server, a subsequent click takes them into the proper transaction thread through the existing onPreviewPressed(action.childReportID) early-return path at the top of the handler, so post-scan UX is unchanged.

Compare branch with the implementation:

https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88783-not-here-after-receipt-review-on-scan-pending?expand=1

This keeps the optimistic-thread creation for the cases where it works correctly (non-scanning expenses missing childReportID due to legacy/migration reasons, e.g. older transactions described in the OpenReport fallback comment at Report/index.ts:1418-1421), and only diverts the one path that the bug demonstrates is unsafe.

The "Not here" outcome is thereby prevented at its source — no orphaned T1 is ever generated for a scan-pending expense — and no behavioral change is introduced for any other flow.

What alternative solutions did you explore? (Optional)

• Auto-redirect from "Not here" in ReportNotFoundInnerGuard when the missing-parent-action condition triggers on a transaction thread: navigate to report.parentReportID automatically. This catches more orphan scenarios but changes "Not here" semantics globally and could mask genuinely-deleted transactions where the page is the correct UX.
• Optimistically merge {[action.reportActionID]: {childReportID: T1, childType: CHAT}} into the IOU report's actions in the click handler itself, on top of what openReport's isCreatingNewReport block already does at Report/index.ts:1636-1648. This is redundant with the existing merge, and the bug indicates the link still does not survive the scan-completion merges — so duplicating the optimistic write does not address the underlying timing.
• Defer the navigation until action.childReportID is set (e.g. a small polling or useOnyx wait inside the click handler). This adds an indeterminate UI delay tied to backend scan latency (often 30-60s), which is a worse UX than navigating to the IOU report immediately.