[$250] Tap back button on detail expense after review duplicates should return to WS chat

[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: 9.1.45-18
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #60292
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Android 13 / Xiaomi Poco F5, iOS 15.8.3 / iPhone 7 Plus, Chrome / Android 13
App Component: Other

Action Performed:

1. Go to workspace chat
2. Submit two expenses with the same amount and merchant
3. Go to transaction thread of the expense
4. Tap Review duplicates
5. Tap the "Keep on this" on the any expense in the list
6. Tap the Confirm
7. Tap the back button

Expected Result:

Tap the back button on the detail expense after review duplicates should return to Workspace chat

Actual Result:

Tap the back button on the detail expense after review duplicates the expense will navigate to the detail expense again

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021925095787861287140
• Upwork Job ID: 1925095787861287140
• Last Price Increase: 2025-05-28
• Automatic offers:
• nkdengineer | Contributor | 107494968

Issue Owner

Current Issue Owner: @MarioExpensify

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (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.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2025-05-15 14:26:08 UTC.

Proposal

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

When a user reviews duplicate expenses, confirms their selection, and then taps the back button on the final confirmation screen, they are incorrectly navigated back to the confirmation screen itself instead of the Workspace chat from which they initiated the review.

What is the root cause of that problem?

The root cause is twofold:

1. The back button action on the Confirmation screen was primarily using the goBack function from the useReviewDuplicatesNavigation hook. This hook's goBack is designed to navigate to the previous step within the duplicate review flow, not necessarily to the screen the user was on before starting the review (e.g., the Workspace chat).
2. The navigation logic after successfully merging or resolving duplicates in the Confirmation screen did not consistently prioritize the backTo route parameter (which should specify the Workspace chat as the return destination). It would sometimes default to Navigation.dismissModalWithReport, which might not lead to the intended backTo route if it was available.

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

The following changes were made in src/pages/TransactionDuplicate/Confirmation.tsx to address the issue:

1. Utilized useNavigation Hook: The component now uses the navigation object obtained from the useNavigation() hook from @react-navigation/native. This provides direct access to navigation dispatch capabilities.

2. Refactored Post-Confirmation Navigation Logic:
   Inside the mergeDuplicates and resolveDuplicates callback functions (which are executed after the user taps "Confirm"):

   • Synchronous Modal Dismissal: The duplicate review modal is first dismissed synchronously using navigation.dispatch({type: CONST.NAVIGATION.ACTION_TYPE.DISMISS_MODAL});. This ensures the modal is closed and the underlying screen becomes active.
   • Screen Replacement: Immediately following the modal dismissal, the navigation to the "Resolved Expense Detail Screen" is performed using a replace action:

     navigation.dispatch(
         StackActions.replace(SCREENS.REPORT, {
             reportID: reportAction.childReportID, // The ID of the merged/resolved transaction's report
         })
     );

     This StackActions.replace call ensures that the current screen in the navigation stack (which would have been the pre-merge transaction detail screen) is replaced with the "Resolved Expense Detail Screen."

3. Outcome: By replacing the screen, the pre-merge/resolution state of the transaction is removed from the navigation history. Consequently, when the user is viewing the "Resolved Expense Detail Screen" and presses the back button, the navigation correctly goes to the screen they were on before initiating the duplicate review flow (e.g., the Workspace chat), eliminating the redundant intermediate step.

output.mp4

The back button behavior on the Confirmation.tsx screen itself (i.e., before the "Confirm" button is pressed) remains handled by the useReviewDuplicatesNavigation hook, which is designed for navigating within the review steps or exiting the flow to the backTo route parameter if specified. The implemented changes specifically target and fix the navigation flow after the duplicate selection is confirmed.

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

none

What alternative solutions did you explore? (Optional)

none

[melvin-bot]

@JmillsExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[JmillsExpensify]

Opening up to the community

[melvin-bot]

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