[Due for payment 2025-08-26] [Multi-Files Drag-and-Drop] Scan - Scan flow reopens after changing To field to self DM and adding another receipt

[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.1.79-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #65678
Email or phone of affected tester (no customers): applausetester+daveec13@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 14.5/ Chrome
App Component: Money Requests

Action Performed:

Precondition:

Log in with Expensifail account.
Have a workspace (make sure it is the default workspace).

1. Go to staging.expensify.com
2. Open FAB > Create expense > Scan.
3. Upload a receipt.
4. On confirmation page, click on the To field (workspace chat).
5. Select Self DM
6. Click RHP back button.
7. Upload another receipt.

Expected Result:

Redirected to the confirmation step

Actual Result:

The first step of scan flow reopens, Not redirected to the confirmation step

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: @stephanieelliott

[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.

[koko57]

ok, please assign me I will check it @mountiny @lakchote

[MobileMage]

Proposal

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

The scan flow reopens after changing the "To" field to self DM and adding another receipt, instead of redirecting to the confirmation step as expected. Additionally, I also identified issue where repeatedly selecting recipients creates nested URL parameters, causing the backTo parameter to be encoded multiple times like backTo=%2Fcreate%2Fcreate%2Fparticipants%2F1%2F6535657166461123%3FbackTo%3D%252Fcreate%252Fsubmit%252Fconfirmation%252F1%252F6535657166461123.

What is the root cause of that problem?

The root cause is in the navigation logic in IOURequestStepParticipants.tsx. When participants are selected, the code checks if a backTo parameter exists and attempts to navigate back to the previous screen using Navigation.goBack(). However, this approach fails when the flow expects to proceed forward to the confirmation step. The navigation logic incorrectly assumes that having a backTo parameter means we should always go back, but in the scan flow after selecting participants, we should move forward to confirmation regardless of the backTo parameter.

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

We should update the navigation logic in IOURequestStepParticipants.tsx to always navigate forward to the next step instead of conditionally going back based on the backTo parameter. The fix involves:

1. Removing the conditional logic that checks for backTo parameter in both navigateToNextStep and navigateToConfirmationStep functions
2. Always using Navigation.navigate() instead of Navigation.goBack() to ensure forward progression in the flow
3. Using Navigation.getActiveRouteWithoutParams() instead of Navigation.getActiveRoute() to avoid accumulating URL parameters

// Before: conditional navigation based on backTo
if (backTo) {
    Navigation.goBack(route, {compareParams: false});
} else {
    Navigation.navigate(route);
}

// After: always navigate forward
Navigation.navigate(route);

This ensures the scan flow always progresses forward to the confirmation step as expected, regardless of how the user arrived at the participants screen.

Before fix

failed.scan.nav.mp4

After fix

fixed.scan.nav.mp4

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We should test the scan flow navigation from participants selection to confirmation step, ensuring that after selecting a recipient (both workspace and self DM), the user is always taken to the confirmation page. Additionally, test that URL parameters don't accumulate when navigating back and forth between participant selection and confirmation screens.

What alternative solutions did you explore? (Optional)

N/A

[dmkt9]

I found the root cause for this issue. Can I create a proposal here?

[dmkt9]

Ah, I see there’s already an open PR for this issue. The PR’s solution is much more complex than the one I found. It only takes a few lines of code to fix this one.