[$250] Expense - User is navigated to Participant page instead of Merchant 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.3.17-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #80480
Email or phone of affected tester (no customers): applausetester+dk6@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 Home/Chrome
App Component: Money Requests

Action Performed:

Preconditions:

• User has some workspaces, but there is not default workspace
• Go to SelfDM, create a manual expense with Merchant

1. Open https://staging.new.expensify.com/
2. Navigate to SelfDM
3. Click 'Submit to someone' under created expense in preconditions
4. Select a workspace in Participant page
5. On Confirmation page, click on '<' button
6. Click on '<' button again

Expected Result:

Test case 8: Tap the back button on the Confirmation page, should go back to the Merchant page (not Participants).

Actual Result:

Step 5 You navigate to Participant page.
Step 6 RHN is closed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abdulrahuman5196

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022021518909383503061
• Upwork Job ID: 2021518909383503061
• Last Price Increase: 2026-05-12

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @RachCHopkins (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]

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

[daledah]

Proposal

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

Actual Result:
Step 5 You navigate to Participant page.
Step 6 RHN is closed

What is the root cause of that problem?

When user clicks "Submit to someone" from an existing expense, selects a workspace in Participants page, and the merchant is required, the app navigates to the Merchant step page. However, when navigating to the Merchant page from Participants page, the backTo parameter is not provided.

App/src/pages/iou/request/step/IOURequestStepParticipants.tsx

Lines 358 to 365 in e0727c9

	} else if (isMerchantRequired) {
	route = ROUTES.MONEY_REQUEST_STEP_MERCHANT.getRoute(
	action,
	iouType === CONST.IOU.TYPE.CREATE || iouType === CONST.IOU.TYPE.TRACK ? CONST.IOU.TYPE.SUBMIT : iouType,
	initialTransactionID,
	newReportID,
	);
	}

The route is created without a backTo parameter. This means on the Merchant page, the backTo prop is undefined. When user clicks the back button on the Merchant page, Navigation.goBack(undefined) is called which closes the RHN instead of navigating back to the Participants page.

App/src/pages/iou/request/step/IOURequestStepMerchant.tsx

Lines 81 to 83 in e0727c9

	const navigateBack = useCallback(() => {
	Navigation.goBack(backTo);
	}, [backTo]);

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

We should pass the Participants page route as the backTo parameter when navigating to the Merchant page from Participants.

In src/pages/iou/request/step/IOURequestStepParticipants.tsx:

} else if (isMerchantRequired) {
    route = ROUTES.MONEY_REQUEST_STEP_MERCHANT.getRoute(
        action,
        iouType === CONST.IOU.TYPE.CREATE || iouType === CONST.IOU.TYPE.TRACK ? CONST.IOU.TYPE.SUBMIT : iouType,
        initialTransactionID,
        newReportID,
+       ROUTES.MONEY_REQUEST_STEP_PARTICIPANTS.getRoute(iouType, initialTransactionID, reportID, undefined, action),
    );
}

What alternative solutions did you explore? (Optional)

An alternative would be to modify the navigateBack function in IOURequestStepMerchant.tsx to handle the case when backTo is undefined by using Navigation.goBack() without parameters. However, this would require additional logic to determine the correct back destination based on the navigation context, which is more complex and error-prone than simply providing the correct backTo parameter upfront.

[HiepPP]

Proposal

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

When a user clicks "Submit to someone" on an expense in SelfDM, selects a workspace in the Participant page, and then presses the back button on the Merchant page, the RHN is closed instead of navigating back to the Participants page.

What is the root cause of that problem?

The navigateBack function in IOURequestStepMerchant.tsx directly calls Navigation.goBack(backTo) without handling the case when backTo is undefined. When navigating from Participants to Merchant (when merchant is required), the backTo parameter is not provided, so clicking back triggers Navigation.goBack(undefined) which closes the RHN.

This is inconsistent with other step components like IOURequestStepWaypoint, IOURequestStepTime, and IOURequestStepSubrate which all check if (backTo) and provide fallback navigation.

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

File: src/pages/iou/request/step/IOURequestStepMerchant.tsx

Key Changes:

1. Update the navigateBack function to check if backTo exists
2. If backTo is undefined, provide a fallback navigation to Participants page

Code Change Location: Lines 81-83 in IOURequestStepMerchant.tsx

const navigateBack = useCallback(() => {
    if (backTo) {
        Navigation.goBack(backTo);
        return;
    }
    // Fallback: navigate back to Participants page when backTo is not provided
    Navigation.goBack(ROUTES.MONEY_REQUEST_STEP_PARTICIPANTS.getRoute(iouType, transactionID, reportID, undefined, action));
}, [backTo, iouType, transactionID, reportID, action]);

This follows the established pattern used in other IOU step components (Waypoint, Time, Subrate) and makes the Merchant page robust regardless of how it's invoked.

What alternative solutions did you explore? (Optional)

Alternative 1: Pass backTo parameter from Participants page when navigating to Merchant.

• Rejected: This only fixes the specific call site. If another caller forgets to pass backTo, the bug reoccurs.

Alternative 2: Check merchant requirement in Confirmation page's navigateBack.

• Rejected: This patches a symptom rather than fixing the root cause. The Merchant page would still have broken navigation when accessed directly.

[github-actions]

⚠️ @HiepPP Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).