[Due for payment 2026-04-14] Reports - Deleted split expense does not show up when filtered with status:deleted

[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.51-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: #85818
Email or phone of affected tester (no customers): oisdjoisdjnoinsjdionj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Open the report.
5. Click More > Split > Save.
6. Open any split.
7. Click More > Delete > Delete.
8. Go to Reports > Expenses.
9. Click Status.
10. Select Deleted and click Apply.

Expected Result:

Deleted split expense will show up.

Actual Result:

Deleted split expense does not show up when filtered with status:deleted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7118502_1774996549904.23.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @jnowakow

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #85818

[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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85818 - "Deleted transactions on search" by @jnowakow (High confidence)
Related Issues: None

Recommendation: ROLL FORWARD

The issue can be fixed with a small code change to the deleted status filter logic. The filter currently only checks for CONST.REPORT.TRASH_REPORT_ID (-1), but split transactions use CONST.REPORT.SPLIT_REPORT_ID (-2) as their reportID, even when deleted. A simple fix is to update the filter to also include split transactions.

Labels: Keeping DeployBlockerCash (App PR caused the issue). Removing DeployBlocker (no backend changes needed).

Detailed Analysis

Evidence

PR #85818 introduced the deleted transaction filter feature for the search functionality. The PR added:

• A new CONST.SEARCH.STATUS.EXPENSE.DELETED status
• A filter in SearchUIUtils.ts that checks: transactionReportID === CONST.REPORT.TRASH_REPORT_ID
• The ability to filter and undelete transactions from search

The issue describes that when you:

1. Create an expense
2. Split it (More > Split > Save)
3. Delete one of the splits (More > Delete)
4. Filter by status:deleted

The deleted split does NOT appear in the filtered results.

Verification

I confirmed that:

1. PR [Payment due @rojiphil] Deleted transactions on search #85818 modified src/libs/SearchUIUtils.ts to add the deleted status filter
2. The filter checks: [CONST.SEARCH.STATUS.EXPENSE.DELETED]: (_expenseReport, transactionReportID) => transactionReportID === CONST.REPORT.TRASH_REPORT_ID (line 356)
3. In CONST/index.ts, there are two separate report IDs:
   • TRASH_REPORT_ID: -1 (for regular deleted transactions)
   • SPLIT_REPORT_ID: -2 (for split transactions)

Root Cause

When a split transaction is deleted, it retains its reportID of CONST.REPORT.SPLIT_REPORT_ID (-2). The deleted status filter in PR #85818 only checks for TRASH_REPORT_ID (-1), causing deleted split transactions to be excluded from the deleted filter results.

The fix should check if a split transaction has been deleted by some other means (e.g., checking if the transaction exists but has pendingAction: DELETE, or the backend should change split transaction reportIDs to TRASH_REPORT_ID when deleted).