[Due for payment 2026-06-02] [$250] Spend - Duplicate expense option is not shown for deleted expense on group-by view

[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.3.68-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-26105/folder/13176670/104397676/1395677532?sort=-identifier
Email or phone of affected tester (no customers): sjdoisndjosjosjdionji@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.2 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense and delete it.
4. Go to Spend > Expenses.
5. Enter status:deleted and search.
6. Select the deleted expense via checkbox.
7. Click dropdown button.
   → Duplicate expense option is shown in the dropdown.
8. Unselect the expense.
9. Enter status:deleted group-by:from and search.
10. Expand the table.
11. Select the deleted expense via checkbox.
12. Click dropdown button.

Expected Result:

Duplicate expense option will be shown for deleted expense on group-by view (consistent with non group-by view in Step 7).

Actual Result:

Duplicate expense option is not shown for deleted expense on group-by view.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7146727_1778121863249.12.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022052782002008443151
• Upwork Job ID: 2052782002008443151
• Last Price Increase: 2026-05-15

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

shouldShowBulkDuplicateOption (useSearchBulkActions.ts:153-155) looks up each selected transaction from allTransactions, which is built by useAllTransactions. This hook merges transactions found in currentSearchResults?.data with the Onyx TRANSACTION collection.

In the non-group-by view, currentSearchResults?.data contains individual transaction entries (e.g., transaction_XYZ), so the lookup succeeds. In the group-by view, currentSearchResults?.data contains only group-level aggregate items — individual transactions are fetched via separate sub-snapshots (useMultipleSnapshots) and never written back to currentSearchResults?.data or the Onyx TRANSACTION collection. So the lookup returns undefined, shouldShowBulkDuplicateOption returns false, and the Duplicate option is hidden.

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

In shouldShowBulkDuplicateOption, instead of only looking up the transaction from allTransactions, fall back to the transaction already stored in selectedTransactions[id]?.transaction (which is populated from the rendered item data, including group-by sub-snapshot data). This way, when the transaction isn't found in allTransactions (as happens in the group-by view), the function can still access the transaction object and evaluate the duplicate eligibility guards.

Specifically, at useSearchBulkActions.ts:154, change:

const transaction = allTransactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${id}`];

to:

const transaction = allTransactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${id}`] ?? selectedTransactions[id]?.transaction;

This is the minimal fix — it uses the same transaction data that's already available in the selection state, requires no changes to useAllTransactions or the snapshot plumbing, and maintains consistent behavior between grouped and non-grouped views.

What alternative solutions did you explore? (Optional)

An alternative would be to modify useAllTransactions to also incorporate transactions from group-by sub-snapshots. However, that would require threading the sub-snapshot data through the search context, which is a larger change with more surface area. The selectedTransactions fallback is simpler and already contains the correct transaction data.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.