[Due for payment 2025-06-05] [$250] iOS - After sorting duplicates, back button returns to infinite loading page or blank report

[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: 9.1.17-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: #58894
Email or phone of affected tester (no customers): applausetester+kok1@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: iPhone 15 Pro Max / iOS 18.3
App Component: Money Requests

Action Performed:

Bug 1 (mweb, Android and iOS app):

1. Launch ND or hybrid app.
2. Go to workspace chat that has no unsettled expenses.
3. Submit two manual expenses with the same amount and merchant.
4. Go to transaction thread of the second expense.
5. Tap Review duplicates.
6. Select Keep this one on the SECOND expense in the list.
7. Tap Confirm.
8. Tap app back button.

Bug 2 (iOS app only):

1. Launch ND or hybrid app.
2. Go to workspace chat that has no unsettled expenses.
3. Submit two manual expenses with the same amount and merchant.
4. Go to transaction thread of the second expense.
5. Tap Review duplicates.
6. Select Keep this one on the FIRST expense in the list.
7. Tap Confirm.
8. Tap app back button.

Expected Result:

Bug 1 (mweb, Android and iOS app):

• App will return to the expense report.

Bug 2 (iOS app only):

• Expense report will not turn blank.

Actual Result:

Bug 1 (mweb, Android and iOS app):

• On Android and iOS, app returns to a page that loads infinitely.
• On mweb, app opens infinite loading page and then auto redirects to expense report.

Bug 2 (iOS app only):

• Expense report turns blank after returning to expense report.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6778676_1742603490438.58894_iOS.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021904203190443191151
• Upwork Job ID: 1904203190443191151
• Last Price Increase: 2025-03-24

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @maddylewis

[melvin-bot]

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

[truph01]

@jjcoffee Mentioning you since we collaborated on the linked PR.

• In Bug 1 (mweb, Android and iOS app):

I referred to the transaction in step 4 ("Go to transaction thread of the second expense") as Transaction A. In step 7, we keep another transaction, which I’ll call Transaction B.

After step 7, Transaction B opens as expected, and Transaction A's data gets cleared — but Transaction A remains in the screen stack. When the user taps the back button in step 8, they’re navigated back to Transaction A.

At this point, we already have logic that redirects the user to the associated expense report if the transaction report has been deleted:

App/src/pages/home/ReportScreen.tsx

Line 559 in 2739a5f

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(prevReport.parentReportID));

It is the explanation of the behavior mentioned in this test step.

• In Bug 2 (iOS app):

I’m able to reproduce this issue now, but I couldn’t reproduce it during testing in this PR.
I’m currently investigating the RCA.