Expense - Unreported split expense cannot be deleted

[applause-bot]

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.90-0
Reproducible in staging?: Yes
Reproducible in production?: No
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-36581/folder/13176670/47002824/1453338367?sort=-identifier
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.com
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:

1. Go to staging.new.expensify.com
2. Go to workspace.
3. Create an expense.
4. Open the expense.
5. Click More > Split > Save.
6. Select all splits via checkbox.
7. Click dropdown button > Move to report > Remove from report.
8. Open any unreported split in self DM.
9. Click More > Delete > Delete.

Expected Result:

Unreported split expense will be deleted.

Actual Result:

Unreported split expense cannot be deleted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7168533_1780317624868.05.mp4

Bug7168533_1780317471556.5.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7168533

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/3d42dc8ebd17a94b90ed826d847952e5b0188e97f198a661faa8239be5d454b5

https://platform.applause.com/services/links/v1/external/bed1984384970d750140ceeb3495633b7b871f7cd008e663578015830bde5a40

[melvin-bot]

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

[MelvinBot]

Issue Analysis

Root cause: Deleting an unreported self-DM split is gated behind an environment check. In production the delete routes to deleteMoneyRequest (real delete); in staging that short-circuit is skipped, so the split instead falls into the split-resize path and calls updateSplitTransactions. No DeleteMoneyRequest command is ever sent, so the expense is never deleted — exactly matching "reproducible in staging, not production."

This is not a new 9.3.90 regression. The production-only guard was added by Expensify/App#91932 ([CP Staging] Add production guard for selfDM splits, merged 2026-05-28, already in production). The staging path was left broken pending the proper fix, which is the open PR Expensify/App#92055 (Fix bugs for selfDM splits feature).

Proposal

What is the root cause of that problem?

In useDeleteTransactions.ts:185-189, the short-circuit that forces an unreported self-DM split into the real delete path is gated on isProduction:

const isUnreportedSelfDMSplit = transaction?.reportID === CONST.REPORT.UNREPORTED_REPORT_ID;
if (isProduction && isUnreportedSelfDMSplit) {   // staging skips this
    acc.nonSplitTransactions.push(item);
    return acc;
}

isProduction comes from useEnvironment(), so it is false on staging. With the guard skipped, the unreported split (created via Split, so it is an expense split with an originalTransactionID) is bucketed into splitTransactionsByOriginalTransactionID and routed to updateSplitTransactions — a "resize the remaining splits" operation, not a delete. The transaction's pendingAction is never set to DELETE and no DeleteMoneyRequest API call is queued, so the confirm modal closes and the row stays.

getChildTransactions carries the same isProduction gate (line 2697), so in staging the sibling splits still count as children, keeping the broken split-resize branch alive.

Why this only repros in staging + verification details

• The delete button is not disabled and there is no reportID === '0' guard blocking it — the action runs, it just calls the wrong API.
• The "redirect to split-expense edit" path (shouldRedirectDeleteToSplitExpenseEdit) is per-diem-only in both environments, so it is not involved for a regular expense split.
• Production path (works): isProduction && isUnreportedSelfDMSplit → nonSplitTransactions → deleteMoneyRequest → DeleteMoneyRequest API.
• Staging path (broken): guard skipped → split bucket → updateSplitTransactions, no delete command.
• Confidence: High — verified directly in code; the environment gating fully explains the staging/production split. Production logs could confirm that the failing flow emits UpdateSplitTransactions rather than DeleteMoneyRequest, but that isn't needed to make the fix.

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

Make the unreported self-DM split delete behave the same in all environments. Two options:

1. Preferred: Fast-track Expensify/App#92055, which already touches src/hooks/useDeleteTransactions.ts and fixes the sibling selfDM-split bugs (Split - Self DM disappears after moving one split to workspace and deleting remaining one. #91913 et al.). Confirm it also covers this single-unreported-split delete case.
2. Quick unblock: Remove the isProduction && condition at useDeleteTransactions.ts:186 (and the matching isProduction gate in getChildTransactions at TransactionUtils/index.ts:2697) so unreported self-DM splits route to deleteMoneyRequest everywhere — i.e. apply the production behavior unconditionally.

Do not revert a 9.3.90 PR — the guard that causes this divergence (#91932) is already in production.

Related issues

• Expensify/App#91913 — Split / self-DM after moving one split and deleting the remaining one (same code area; linked in Fix bugs for selfDM splits feature #92055).
• Expensify/App#85484 — Cannot delete unreported expense in bulk from new dot (same delete path).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92231) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.