[$250] Scan-Error modal is not displayed when Retry fails

[mitarachim]

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.26-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: #77646
Email or phone of affected tester (no customers): agexptest+pr250226b@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.1
App Component: Money Requests

Action Performed:

1. Open the Expensify app
2. Go to Troubleshoot > Enable Simulate failing network requests
3. Create a scan expense
4. Go to the expense details
5. Wait until the error message appears
6. Tap "Retry" link
7. Wait for the confirm modal

Expected Result:

A confirm modal with a generic error message and "OK" button appears.

Actual Result:

The confirm modal does not appear. After dismissing the error message, the app redirects to the workspace room.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7088710_1772059569218.No_confirm_modal.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @blimpich

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026910439458013314
• Upwork Job ID: 2026910439458013314
• Last Price Increase: 2026-02-26

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

Proposal

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

When a user creates a scan expense with "Simulate failing network requests" enabled and taps "Retry" after the error appears, the expected confirm modal (with a generic error message and "OK" button) does not appear. Additionally, after dismissing the error message, the app redirects to the workspace room instead of staying on the expense details page.

What is the root cause of that problem?

PR #77646 refactored DotIndicatorMessage.tsx to replace an inline <ConfirmModal> component (controlled by local useState) with the useConfirmModal hook from the global modal system. This introduced a behavioral change:

The shouldHandleNavigationBack: true default: In src/hooks/useConfirmModal.ts:14, the hook always sets shouldHandleNavigationBack: true as a default prop when showing modals. The old inline ConfirmModal in DotIndicatorMessage did not have this prop set (defaulting to undefined/false).

The retry flow works as follows:

1. User taps "Retry" → handleRetryPress in ReceiptUploadRetryHandler attempts to reconstruct the receipt file from local storage
2. On Android (index.android.ts), RNFS reads the local file; on iOS (index.ts), fetch(message.source) is called
3. If file reconstruction fails, the error modal callback is triggered (this is the modal the issue is about)
4. If file reconstruction succeeds, handleFileRetry calls dismissError() and re-dispatches the IOU action — no modal is shown

When file reconstruction fails and the modal callback IS triggered, the new code calls showConfirmModal() which renders via the global ModalProvider at the app root level with shouldHandleNavigationBack: true. On web, this causes window.history.back() when the modal is dismissed, potentially navigating the user away. On native, this prop is not consumed by BaseModal directly but may affect the modal lifecycle through the ConfirmModalWrapper bridge component.

The old inline ConfirmModal was rendered within DotIndicatorMessage's component tree and was always present in the DOM (just toggled via isVisible). The new approach mounts a fresh ConfirmModalWrapper into the ModalProvider only when triggered — this changes the rendering lifecycle and may interact differently with React Native's modal system on native platforms.

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

In src/components/DotIndicatorMessage.tsx, pass shouldHandleNavigationBack: false in the showConfirmModal call to match the old inline ConfirmModal behavior:

showConfirmModal({
    prompt: translate('common.genericErrorMessage'),
    confirmText: translate('common.ok'),
    shouldShowCancelButton: false,
    shouldHandleNavigationBack: false,
});

This restores the behavior where dismissing the error modal does NOT trigger a navigation back action.

If this alone doesn't resolve the issue on native platforms, the DotIndicatorMessage should be reverted to use an inline ConfirmModal with local useState (as it was before PR #77646), until the global modal system's native rendering is verified to work correctly in all contexts.

What alternative solutions did you explore? (Optional)

1. Changing the default in useConfirmModal.ts to shouldHandleNavigationBack: false — this would affect all consumers of the hook and might break other modals that rely on the navigation back behavior.
2. Investigating the ModalProvider rendering on native — the global modal system renders via ModalProvider at the app root. If there are issues with how ConfirmModalWrapper renders on native (timing, animation, z-index), those should be fixed in the modal system itself. However, the quickest fix is to match the old behavior for this specific modal.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[twilight2294]

Proposal

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

When a user creates a scan expense with "Simulate failing network requests" enabled and taps "Retry" after the initial error appears, the expected scan-error confirm modal does not display. Additionally, the app navigates away from the expense details page to the workspace room.

What is the root cause of that problem?

The root cause is in handleFileRetry() in handleFileRetry. When "Retry" is pressed, this function calls dismissError() before re-dispatching the IOU action. The dismissError callback originates from dismissReceiptError() in MoneyRequestReceiptView.

When transaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD, dismissReceiptError() calls cleanUpMoneyRequest(), which deletes the entire transaction, report action, and associated report — then navigates the user away. This is correct behavior when the user wants to permanently dismiss an error, but it is destructive when called as part of a retry flow.

After dismissError() destroys the transaction context, requestMoney() (or trackExpense()) is called to create a brand new expense. Because "Simulate failing network requests" is enabled, this new request also fails. However, the user has already been navigated away from the original expense details page (since the underlying report was deleted by cleanUpMoneyRequest()), so they never see the new error or the scan-error modal. The modal callback passed as setShouldShowErrorModal in DotIndicatorMessage is never triggered because the retry's file-fetch succeeds — the failure happens later at the network level, after the component has already unmounted due to the navigation caused by cleanup.

This is fundamentally different from the existing proposal's root cause, which focuses on shouldHandleNavigationBack in the useConfirmModal hook. The real problem is that the retry flow never gets to the point of showing any modal at all — the transaction and its containing report are deleted before the retry request can fail and surface an error.

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

In handleFileRetry, instead of calling the full dismissError() (which triggers cleanUpMoneyRequest and navigates away), we should only clear the transaction errors. We can use Transaction.clearError() to remove the error from the transaction without destroying the entire money request context:

// In handleFileRetry.ts
import * as Transaction from '@libs/actions/Transaction';

function handleFileRetry(
    retryParams: ReceiptError['retryParams'],
    file: FileObject,
    transactionID: string,
    setShouldShowErrorModal: () => void,
) {
    switch (retryParams.actionType) {
        case CONST.IOU.ACTION_PARAMS.MONEY_REQUEST: {
            Transaction.clearError(transactionID);
            const requestMoneyParams = {...retryParams} as IOU.RequestMoneyInformation;
            requestMoneyParams.transactionParams.receipt = file;
            requestMoneyParams.isRetry = true;
            requestMoneyParams.shouldPlaySound = false;
            IOU.requestMoney(requestMoneyParams);
            break;
        }
        case CONST.IOU.ACTION_PARAMS.TRACK_EXPENSE: {
            Transaction.clearError(transactionID);
            const trackExpenseParams = {...retryParams} as IOU.TrackExpenseInformation;
            trackExpenseParams.transactionParams.receipt = file;
            trackExpenseParams.isRetry = true;
            trackExpenseParams.shouldPlaySound = false;
            IOU.trackExpense(trackExpenseParams);
            break;
        }
        // ... other cases similarly updated
    }
}

The transactionID can be obtained from the retryParams (already available as retryParams.transactionParams.transactionID) and threaded through from DotIndicatorMessage where receiptError already contains the transaction details. This way, the error is cleared so the UI updates, but the transaction and report remain intact for the retry to operate on. If the retry fails again, the error will be re-set on the same transaction and the user will remain on the same page to see it.

What alternative solutions did you explore? (Optional)

1. Adding a isRetry flag to dismissReceiptError — This would skip the cleanUpMoneyRequest path when called from a retry context. However, this leaks retry-awareness into a function that shouldn't need to know about it, and the cleaner approach is to simply not call the full dismiss flow during retries.

2. Calling Onyx.merge directly to clear just the transaction errors — This would work but using the existing Transaction.clearError() action is more consistent with the codebase patterns.

[marufsharifi]

Proposal

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

When a user retries a failed scan expense, the app should keep them on the same expense context and show the proper retry failure UX.
Instead, retry can navigate the user away (workspace/concierge flow), and the expected scan-error modal is not shown.

What is the root cause of that problem?

The retry handler calls dismissError() before dispatching retry actions (requestMoney, trackExpense, etc.):

App/src/libs/ReceiptUploadRetryHandler/handleFileRetry.ts

Lines 13 to 43 in a152afa

	case CONST.IOU.ACTION_PARAMS.REPLACE_RECEIPT: {
	dismissError();
	const replaceReceiptParams = {...retryParams} as IOU.ReplaceReceipt;
	replaceReceiptParams.file = file;
	IOU.replaceReceipt(replaceReceiptParams);
	break;
	}
	case CONST.IOU.ACTION_PARAMS.START_SPLIT_BILL: {
	dismissError();
	const startSplitBillParams = {...retryParams} as IOU.StartSplitBilActionParams;
	startSplitBillParams.receipt = file;
	startSplitBillParams.shouldPlaySound = false;
	startSplitBill(startSplitBillParams);
	break;
	}
	case CONST.IOU.ACTION_PARAMS.TRACK_EXPENSE: {
	dismissError();
	const trackExpenseParams = {...retryParams} as IOU.CreateTrackExpenseParams;
	trackExpenseParams.transactionParams.receipt = file;
	trackExpenseParams.isRetry = true;
	trackExpenseParams.shouldPlaySound = false;
	IOU.trackExpense(trackExpenseParams);
	break;
	}
	case CONST.IOU.ACTION_PARAMS.MONEY_REQUEST: {
	dismissError();
	const requestMoneyParams = {...retryParams} as IOU.RequestMoneyInformation;
	requestMoneyParams.transactionParams.receipt = file;
	requestMoneyParams.isRetry = true;
	requestMoneyParams.shouldPlaySound = false;
	IOU.requestMoney(requestMoneyParams);

For scan expenses in pending ADD state, that dismiss path is destructive:

dismissReceiptError() enters pendingAction === ADD branch:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 267 to 284 in a152afa

	if (transaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD) {
	if (chatReport?.reportID && getCreationReportErrors(chatReport)) {
	navigateToConciergeChatAndDeleteReport(chatReport.reportID, conciergeReportID, true, true);
	return;
	}
	if (parentReportAction) {
	cleanUpMoneyRequest(
	transaction?.transactionID ?? linkedTransactionID,
	parentReportAction,
	report.reportID,
	iouReport,
	chatIOUReport,
	isChatIOUReportArchived,
	originalReportID,
	true,
	);
	return;
	}

• It can call cleanUpMoneyRequest(...) and navigate away, removing the transaction/report context before retry failure is surfaced.

So the issue is a retry flow bug (destructive dismiss during retry), not primarily a modal rendering bug.

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

Use a non-destructive retry flow:

1. Stop calling full dismissError() in handleFileRetry for retryable actions.
2. Clear only transaction error state (Transaction.clearError) before retrying.
3. Preserve context by including transactionID in receipt-error payload created by getReceiptError(...).
4. Keep destructive dismiss behavior only for explicit user dismissal (not retry).

Non-destructive retry in handleFileRetry.ts

diff --git a/src/libs/ReceiptUploadRetryHandler/handleFileRetry.ts b/src/libs/ReceiptUploadRetryHandler/handleFileRetry.ts
index a8e7dae2cc1..5fd427026ab 100644
--- a/src/libs/ReceiptUploadRetryHandler/handleFileRetry.ts
+++ b/src/libs/ReceiptUploadRetryHandler/handleFileRetry.ts
@@ -1,5 +1,6 @@
 import * as IOU from '@userActions/IOU';
 import {startSplitBill} from '@userActions/IOU/Split';
+import {clearError} from '@userActions/Transaction';
 import CONST from '@src/CONST';
 import type {ReceiptError} from '@src/types/onyx/Transaction';
 
@@ -8,17 +9,26 @@ export default function handleFileRetry(message: ReceiptError, file: File, dismi
         typeof message.retryParams === 'string'
             ? (JSON.parse(message.retryParams) as IOU.ReplaceReceipt | IOU.StartSplitBilActionParams | IOU.CreateTrackExpenseParams | IOU.RequestMoneyInformation)
             : message.retryParams;
+    const clearReceiptError = () => {
+        const fallbackTransactionID = message.action === CONST.IOU.ACTION_PARAMS.REPLACE_RECEIPT ? (retryParams as IOU.ReplaceReceipt).transactionID : undefined;
+        const transactionID = message.transactionID ?? fallbackTransactionID;
+
+        if (!transactionID) {
+            return;
+        }
+        clearError(transactionID);
+    };
 
     switch (message.action) {
         case CONST.IOU.ACTION_PARAMS.REPLACE_RECEIPT: {
-            dismissError();
+            clearReceiptError();
             const replaceReceiptParams = {...retryParams} as IOU.ReplaceReceipt;
             replaceReceiptParams.file = file;
             IOU.replaceReceipt(replaceReceiptParams);
             break;
         }
         case CONST.IOU.ACTION_PARAMS.START_SPLIT_BILL: {
-            dismissError();
+            clearReceiptError();
             const startSplitBillParams = {...retryParams} as IOU.StartSplitBilActionParams;
             startSplitBillParams.receipt = file;
             startSplitBillParams.shouldPlaySound = false;
@@ -26,7 +36,7 @@ export default function handleFileRetry(message: ReceiptError, file: File, dismi
             break;
         }
         case CONST.IOU.ACTION_PARAMS.TRACK_EXPENSE: {
-            dismissError();
+            clearReceiptError();
             const trackExpenseParams = {...retryParams} as IOU.CreateTrackExpenseParams;
             trackExpenseParams.transactionParams.receipt = file;
             trackExpenseParams.isRetry = true;
@@ -35,7 +45,7 @@ export default function handleFileRetry(message: ReceiptError, file: File, dismi
             break;
         }
         case CONST.IOU.ACTION_PARAMS.MONEY_REQUEST: {
-            dismissError();
+            clearReceiptError();
             const requestMoneyParams = {...retryParams} as IOU.RequestMoneyInformation;
             requestMoneyParams.transactionParams.receipt = file;
             requestMoneyParams.isRetry = true;
@@ -44,6 +54,7 @@ export default function handleFileRetry(message: ReceiptError, file: File, dismi
             break;
         }
         default:
+            dismissError();
             setShouldShowErrorModal(true);
             break;
     }

Description: Retry actions now clear only transaction errors and keep the expense/report context intact.

Extend receipt error type in Transaction.ts

diff --git a/src/types/onyx/Transaction.ts b/src/types/onyx/Transaction.ts
index 58fcb8c57f9..1e0cc82511e 100644
--- a/src/types/onyx/Transaction.ts
+++ b/src/types/onyx/Transaction.ts
@@ -255,6 +255,9 @@ type ReceiptError = {
 
     /** Parameters required to retry the failed action */
     retryParams: StartSplitBilActionParams | CreateTrackExpenseParams | RequestMoneyInformation | ReplaceReceipt;
+
+    /** Transaction ID associated with the receipt error */
+    transactionID?: string;
 };
 

• In src/libs/actions/IOU/index.tsUpdate getReceiptError() signature to accept optional transactionID, and include it in the receipt-error payload object.
• In src/libs/actions/IOU/index.tsPass transaction.transactionID / transactionID into getReceiptError() at all receipt-retry error creation points:
  • Money request receipt error writes
  • Track expense receipt error writes
  • Replace receipt receipt error write

What alternative solutions did you explore? (Optional)

1. Setting shouldHandleNavigationBack: false in showConfirmModal (local fix in DotIndicatorMessage): mitigates one modal behavior but does not solve destructive cleanup in retry path.
2. Changing default behavior globally in useConfirmModal: too broad and risky for unrelated modals.
3. Passing retry flags through dismissReceiptError: possible, but leaks retry-specific behavior into a general dismiss function and is less clean than making retry non-destructive by design.