[Due for payment 2025-11-18] [Due for payment 2025-11-17] Expense - Create expense page opens when navigate back from Confirm details page

[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.2.47-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: Exploratory
Email or phone of affected tester (no customers): gocemate+b2155051@gmail.com
Issue reported by: Applause Internal Team
Device used: Lenovo 80ES / Windows 10 Pro
App Component: Other

Action Performed:

Precondition:

1. Create two workspace - A and B.

2. Workspace A is the default workspace.

3. Go to workspace chat A> Create two empty reports and rename it to A and B respectively.

4. Go to workspace chat B.> Create an empty report and rename it to C.

5. Open FAB > Create expense > Manual> Enter amount > Next.

6. On confirm page, click Report field.

7. Select Report C.

8. Click RHP back button.

9. Click Next.

Expected Result:

Confirm details page should be displayed

Actual Result:

Create expense page is displayed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @twisterdotcom

[melvin-bot]

Triggered auto assignment to @twisterdotcom (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 @mollfpr (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[abbasifaizan70]

Proposal

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

When creating an expense from the global FAB (Floating Action Button), if a user:

1. Navigates to the confirmation page
2. Clicks the Report field to select a report
3. Selects a report from a different workspace (e.g., Report C from Workspace B)
4. Clicks the RHP (Right Hand Panel) back button
5. Clicks Next

Expected Result: The confirmation details page should be displayed with the selected report.

Actual Result: The create expense page is displayed instead of the confirmation page.

What is the root cause of that problem?

The root cause is in the handleGlobalCreateReport function in IOURequestStepReport.tsx. When a user selects a report from a different workspace during expense creation:

1. The function correctly updates the transaction's reportID and participants via setTransactionReport
2. It navigates back to the confirmation page using Navigation.goBack(iouConfirmationPageRoute, {compareParams: false})
3. However, it does not update the route parameters on the confirmation page with the new reportID

When the user clicks back and then Next, the confirmation page still has the old reportID in its route parameters. The confirmation page's useEffect hook (lines 324-351) checks if the transaction belongs to the current report using the route's reportID parameter. Since the route still has the old reportID but the transaction now has the new reportID, the check fails. This causes the confirmation page to think the transaction doesn't belong to the current report, triggering startMoneyRequest which navigates the user to the create expense page instead of staying on the confirmation page.

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

In the handleGlobalCreateReport function in IOURequestStepReport.tsx, after navigating back to the confirmation page, we should update the route parameters to include the new reportID. This ensures the confirmation page has the correct reportID in its route params, allowing it to properly match the transaction with the report.

Code Change:

In src/pages/iou/request/step/IOURequestStepReport.tsx, update the handleGlobalCreateReport function.

Before:

const iouConfirmationPageRoute = ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(action, iouType, transactionID, reportOrDraftReportFromValue?.chatReportID);
// If the backTo parameter is set, we should navigate back to the confirmation screen that is already on the stack.
if (backTo) {
    Navigation.goBack(iouConfirmationPageRoute, {compareParams: false});
} else {
    Navigation.navigate(iouConfirmationPageRoute);
}

After:

const iouConfirmationPageRoute = ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(action, iouType, transactionID, reportOrDraftReportFromValue?.chatReportID);
// If the backTo parameter is set, we should navigate back to the confirmation screen that is already on the stack.
// We need to update the route params to ensure the confirmation page has the correct reportID.
if (backTo) {
    Navigation.goBack(iouConfirmationPageRoute, {compareParams: false});
    // Update the route params on the confirmation page to ensure it has the correct reportID
    // Use InteractionManager to ensure navigation completes before updating params
    // eslint-disable-next-line @typescript-eslint/no-deprecated
    InteractionManager.runAfterInteractions(() => {
        Navigation.setParams({reportID: reportOrDraftReportFromValue?.chatReportID});
    });
} else {
    Navigation.navigate(iouConfirmationPageRoute);
}

Full function context:

const handleGlobalCreateReport = (item: TransactionGroupListItem) => {
    if (!transaction) {
        return;
    }
    const reportOrDraftReportFromValue = getReportOrDraftReport(item.value);
    const participants = [
        {
            selected: true,
            accountID: 0,
            isPolicyExpenseChat: true,
            reportID: reportOrDraftReportFromValue?.chatReportID,
            policyID: reportOrDraftReportFromValue?.policyID,
        },
    ];

    setTransactionReport(
        transaction.transactionID,
        {
            reportID: item.value,
            participants,
        },
        true,
    );

    const iouConfirmationPageRoute = ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(action, iouType, transactionID, reportOrDraftReportFromValue?.chatReportID);
    // If the backTo parameter is set, we should navigate back to the confirmation screen that is already on the stack.
    // We need to update the route params to ensure the confirmation page has the correct reportID.
    if (backTo) {
        Navigation.goBack(iouConfirmationPageRoute, {compareParams: false});
        // Update the route params on the confirmation page to ensure it has the correct reportID
        // Use InteractionManager to ensure navigation completes before updating params
        // eslint-disable-next-line @typescript-eslint/no-deprecated
        InteractionManager.runAfterInteractions(() => {
            Navigation.setParams({reportID: reportOrDraftReportFromValue?.chatReportID});
        });
    } else {
        Navigation.navigate(iouConfirmationPageRoute);
    }
};

Key Changes:

• Added a call to Navigation.setParams({reportID: reportOrDraftReportFromValue?.chatReportID}) after Navigation.goBack()
• Wrapped the setParams call in InteractionManager.runAfterInteractions() to ensure navigation completes before updating params
• Added comments explaining why we're updating the route params

This approach:

1. Ensures the navigation completes before updating params (using InteractionManager.runAfterInteractions)
2. Updates the confirmation page route with the correct reportID
3. Allows the confirmation page's validation logic to correctly identify that the transaction belongs to the current report
4. Prevents the unwanted navigation to the create expense page

The fix is minimal and follows the existing pattern in the same file where InteractionManager.runAfterInteractions is already used for similar async operations after navigation (see lines 120 and 175).

What alternative solutions did you explore? (Optional)

1. Updating the confirmation page's validation logic: Instead of fixing the route params, we could modify the confirmation page to use the transaction's reportID directly rather than relying on the route params. However, this would be a more invasive change and could affect other flows. The route params should be the source of truth for the current report context.

2. Using Navigation.navigate instead of Navigation.goBack: We could navigate to a new confirmation page instance instead of going back. However, this would create a new navigation stack entry unnecessarily and doesn't match the expected user flow where they should return to the existing confirmation page.

3. Using Navigation.isNavigationReady(): We could use Navigation.isNavigationReady() instead of InteractionManager.runAfterInteractions. However, InteractionManager.runAfterInteractions is already used in this file for similar operations and is more appropriate for ensuring animations/interactions complete before updating params.

The chosen solution is the most minimal and consistent with existing patterns in the codebase.

[situchan]

Confirmed regression from #73354. Looks like it caused 2 deploy blockers. Maybe revert?

[mollfpr]

Thanks @situchan! I was going to do bisect. Let me try the revert PR!