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] Expense is not moved to self DM after switching to table view and deleting report from More #103387
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: Mac 26.5 / Chrome App Component: Money Requests
Action Performed:
Go to staging.new.expensify.com
Go to workspace chat.
Create an expense.
Open the report.
Click More > Switch to table view.
Click More > Delete > Delete.
Expected Result:
Expense will be moved to self DM after switching to table view and deleting report from More menu.
Actual Result:
Expense is not moved to self DM after switching to table view and deleting report from More menu.
👋 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: The More > Delete handler chooses its path by expense count, not by view. When a report has one expense you own, Delete always takes the "Delete expense" path. That path permanently deletes the expense instead of calling deleteAppReport, which moves expenses to self DM (useExpenseActions.ts#L537). The PR lets a single-expense report render as a table, but it did not update Delete to use report-level delete in that view.
Recommendation: fix forward. The fix is small. Reverting would remove a 34-file opt-in feature. In src/hooks/useExpenseActions.ts, skip the single-expense path when the table view is on:
Also add !shouldUseTableViewForSingleExpense to shouldShowEditSplitOnDeleteAction (L198). Otherwise the menu could say "Edit splits" while the action deletes the report.
If product decides that "Delete expense" is correct in the table view, you can demote this instead. The default view behaves the same way, and the confirm modal already says "Delete expense".
Other PRs ruled out: No other PR in the current deploy checklist touches the delete code (useExpenseActions.ts, useDeleteTransactions.ts, deleteAppReport). That code is unchanged between production 9.5.4-3 and main.
Default view: Deleting from the default view also permanently deletes the expense. That is existing production behavior. The bug appears only when users expect report-level delete in a table-layout report.
Test to add: With the table view on and a single-expense report you own, confirm Delete. Expect deleteAppReport to be called and deleteTransactions not to be called.
Not verified: I couldn't open the Applause video, so I didn't confirm the staging modal text visually. I traced the mechanism through the code.
Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.
changed the title [-]Expense is not moved to self DM after switching to table view and deleting report from More[/-][+][Due for payment 2026-10-30] Expense is not moved to self DM after switching to table view and deleting report from More[/+]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 7, 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/dc899b3c0639c695d6e8f01e080f72c297df2562a6774b2a5dc0e2567cafa2b8
melvin-bot commentedon Oct 7, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #103121
melvin-bot commentedon Oct 7, 2026
@Beamanator @daledah you have been assigned to this deploy blocker because you reviewed the offending PR: #103121
melvin-bot commentedon Oct 7, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Oct 7, 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 7, 2026
Deploy Blocker Analysis
Causing PR: Add a More menu option to switch single-expense reports between expense view and table view (
Expensify/App#103121), merged 2026-10-07. This is a gap in a new feature, not a regression in existing behavior. Production is not affected.Root cause: The More > Delete handler chooses its path by expense count, not by view. When a report has one expense you own, Delete always takes the "Delete expense" path. That path permanently deletes the expense instead of calling
deleteAppReport, which moves expenses to self DM (useExpenseActions.ts#L537). The PR lets a single-expense report render as a table, but it did not update Delete to use report-level delete in that view.Recommendation: fix forward. The fix is small. Reverting would remove a 34-file opt-in feature. In
src/hooks/useExpenseActions.ts, skip the single-expense path when the table view is on:Also add
!shouldUseTableViewForSingleExpensetoshouldShowEditSplitOnDeleteAction(L198). Otherwise the menu could say "Edit splits" while the action deletes the report.If product decides that "Delete expense" is correct in the table view, you can demote this instead. The default view behaves the same way, and the confirm modal already says "Delete expense".
Investigation details
deleteTransactions. This path never moves anything to self DM (useExpenseActions.ts#L535-L603). Any other case → "Delete report" →deleteAppReport(useExpenseActions.ts#L605-L644).deleteAppReportmoves the owner's expenses to self DM (Report/index.ts#L7195-L7199).MoneyReportHeaderSecondaryActionsmenu, so Delete behaves the same in both.useExpenseActions.ts,useDeleteTransactions.ts,deleteAppReport). That code is unchanged between production9.5.4-3andmain.deleteAppReportto be called anddeleteTransactionsnot to be called.Next Steps: Reply with
@MelvinBot implement thisto create a draft PR, or@MelvinBot <your feedback>to refine this analysis.view run
melvin-bot commentedon Oct 7, 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 7, 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.
[-]Expense is not moved to self DM after switching to table view and deleting report from More[/-][+][Due for payment 2026-10-30] Expense is not moved to self DM after switching to table view and deleting report from More[/+]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]