You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-10-30] Report -User lands on "It´s not here" page after keeping one duplicate while in Table View #103425
Version Number: 9.5.5-0 Reproducible in staging?: Yes Reproducible in production?: N/A - new feature, doesn't exist in prod If this was caught during regression testing, add the test name, ID and link from BrowserStack:#103121 Email or phone of affected tester (no customers):[email protected] Issue reported by: Applause Internal Team Bug source: Exploratory - Significant User Experience Deterioration Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome App Component: Money Requests
Action Performed:
Prerequisite: Account has a workspace.
Open the staging.new.expensify.com website.
Open any workspace chat.
Create a manual expense.
Open the just created expense.
Click on "More" > "Switch to table view"
Click on "More" > "Duplicate Report"
Navigate to the new report.
Click on "Review Duplicates"
Select the expense from the other report > "Keep Selected" > "Confirm"
Note that you land on "It´s not here" page.
Expected Result:
After keeping one duplicate, user should land on report of the kept expense.
Actual Result:
After keeping one duplicate while in "Table View", user lands on "It´s not here" page.
👋 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:
Identify the pull request that introduced this issue and revert it.
Root cause: Table view makes a single-expense report use the super-wide panel. After the merge, the Confirm step returns the user to that panel instead of the kept report. That report just lost its only expense, so it shows "It's not here".
Investigation details
Code references use App commit 4bb6832, which includes the PR.
Before the PR, a single-expense report never used the super-wide panel, so the flow always took the L133-136 path. That is the expected result in this issue.
Other PRs checked: No other PR in the 9.5.5-0 checklist touches the duplicate-review flow, the panel-width logic, or table view.
Android: Not confirmed in code. On native, the panel-width hook does nothing (useRHPWidth/index.native.ts:3-4), so Android takes a different branch. It still only happens in table view, which only exists because of this PR, so the revert fixes both platforms.
Fix to include when the PR is re-landed: In handleMergeDuplicates, only call dismissToSuperWideRHP() when the current report still has expenses after the merge. Otherwise use the existing dismissModal + navigate(keptReportRoute, {forceReplace: true}) path. Better still, base the decision on the report's expense count, not the panel width, since table view now separates the two. Verify the Android path on a device before re-landing.
Next Steps: Merge the revert PR, or reply with @MelvinBot <your feedback> to refine this analysis.
changed the title [-]Report -User lands on "It´s not here" page after keeping one duplicate while in Table View[/-][+][Due for payment 2026-10-30] Report -User lands on "It´s not here" page after keeping one duplicate while in Table View[/+]on Oct 23, 2026
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.18-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-10-30. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]
Activity
applause-bot commentedon Oct 8, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/6961ef2fef7b82ecc74c3168a18084e77691ec4ebc4b42833d5502b08e5bf5d1
melvin-bot commentedon Oct 8, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #103121
melvin-bot commentedon Oct 8, 2026
@Beamanator @daledah you have been assigned to this deploy blocker because you reviewed the offending PR: #103121
melvin-bot commentedon Oct 8, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Oct 8, 2026
👋 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:
MelvinBot commentedon Oct 8, 2026
Deploy Blocker Analysis
Causing PR: Add a More menu option to switch single-expense reports between expense view and table view (high confidence on web).
Recommendation: revert. A mergeable revert already exists: Revert "Add a More menu option to switch single-expense reports between expense view and table view". That PR has caused several table-view blockers on this checklist, so one-by-one fixes aren't realistic before the deploy.
Root cause: Table view makes a single-expense report use the super-wide panel. After the merge, the Confirm step returns the user to that panel instead of the kept report. That report just lost its only expense, so it shows "It's not here".
Investigation details
Code references use App commit
4bb6832, which includes the PR.handleMergeDuplicatesbuilds the kept-report route (DynamicConfirmationPage.tsx:113). When the super-wide panel shows, it callsdismissToSuperWideRHP()and returns early (DynamicConfirmationPage.tsx:124-127). It never reaches the navigate-to-kept-report path (L133-136).mergeDuplicatesdeletes the discarded expense from the new report (Duplicate.ts:224-228). The report is now empty, so its not-found check fires (SearchMoneyRequestReportPage.tsx:339-356).Other PRs checked: No other PR in the 9.5.5-0 checklist touches the duplicate-review flow, the panel-width logic, or table view.
Android: Not confirmed in code. On native, the panel-width hook does nothing (useRHPWidth/index.native.ts:3-4), so Android takes a different branch. It still only happens in table view, which only exists because of this PR, so the revert fixes both platforms.
Related: Expense - Not here page opens after switching to table view and deleting expense looks like the same pattern: the user returns to a report that just became empty.
Fix to include when the PR is re-landed: In
handleMergeDuplicates, only calldismissToSuperWideRHP()when the current report still has expenses after the merge. Otherwise use the existingdismissModal+navigate(keptReportRoute, {forceReplace: true})path. Better still, base the decision on the report's expense count, not the panel width, since table view now separates the two. Verify the Android path on a device before re-landing.Next Steps: Merge the revert PR, or reply with
@MelvinBot <your feedback>to refine this analysis.view run
melvin-bot commentedon Oct 8, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
melvin-bot commentedon Oct 8, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
19 remaining items
melvin-bot commentedon Oct 21, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
mitarachim commentedon Oct 21, 2026
Deploy Blocker #104657 was identified to be related to the PR #103703 that attempted to fix this issue.
melvin-bot commentedon Oct 21, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
melvin-bot commentedon Oct 22, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104676 was identified to be related to the PR #103703 that attempted to fix this issue.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104678 was identified to be related to the PR #103703 that attempted to fix this issue.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104681 was identified to be related to the PR #103703 that attempted to fix this issue.
melvin-bot commentedon Oct 22, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
jponikarchuk commentedon Oct 22, 2026
Deploy Blocker #104682 was identified to be related to the PR #103703 that attempted to fix this issue.
melvin-bot commentedon Oct 22, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
[-]Report -User lands on "It´s not here" page after keeping one duplicate while in Table View[/-][+][Due for payment 2026-10-30] Report -User lands on "It´s not here" page after keeping one duplicate while in Table View[/+]melvin-bot commentedon Oct 23, 2026
@daledah
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.18-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-10-30. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]