Expense - Expense briefly disappears from background when deleting expense

[vincdargento]

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.7-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: #80107
Email or phone of affected tester (no customers): applausetester+t1sab@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Web
App Component: Other

Action Performed:

1. Open a chat with another user.
2. Create the first expense.
3. Create a second expense without opening it.
4. Delete the first expense.
5. Observe the background expense.

Expected Result:

Expense briefly disappears for a moment when the expense is deleted.

Actual Result:

The background expense should remain visible and stable

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

Triggered auto assignment to @heyjennahay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[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: #80107 - "Fix: Display MoneyRequestReport as single transaction after deleting others" by @collectioneur (High confidence)
Related Issues: #79732 (the issue that #80107 was fixing)

Recommendation: ROLL FORWARD

While PR #80107 fixed a legitimate issue (#79732 - transactions not displaying after deletion), it introduced this visual regression. The fix should be relatively straightforward: refine the useEffect logic to avoid calling openReport() unnecessarily when oneTransactionID changes during transaction deletion. A revert would reintroduce the original bug where remaining transactions fail to display.

Labels: Keeping DeployBlockerCash (this is an App/frontend issue that needs to be fixed in the App repository before deploying to mobile)

📋 Detailed Analysis

Evidence

• PR Fix: Display MoneyRequestReport as single transaction after deleting others #80107 was merged on 2026-01-22 and is in the 9.3.7-0 staging release
• The issue is reproducible only in staging (9.3.7-0), not in production, confirming it was introduced by this release
• The bug was caught during QA of PR Fix: Display MoneyRequestReport as single transaction after deleting others #80107 itself
• The reproduction steps match the scenario that PR Fix: Display MoneyRequestReport as single transaction after deleting others #80107 was designed to handle (deleting transactions)

Verification

The affected file is src/pages/Search/SearchMoneyRequestReportPage.tsx, which was modified by PR #80107.

Key change in PR #80107:

// Before: useEffect dependencies
}, [reportIDFromRoute, transactionThreadReportID]);

// After: added oneTransactionID
}, [reportIDFromRoute, transactionThreadReportID, oneTransactionID]);

This change causes the useEffect (lines 165-185) to re-run whenever oneTransactionID changes, which happens when a transaction is deleted.

Root Cause

When you delete a transaction:

1. oneTransactionID updates from the deleted transaction ID to the remaining transaction ID
2. The useEffect re-runs due to the new dependency
3. openReport(reportIDFromRoute, ...) is called again (line 177)
4. This causes an unnecessary report refresh/re-render
5. The visual result is that the background expense briefly flickers/disappears

The problem: While oneTransactionID was added to handle the case where transactions are deleted and need to be re-displayed correctly, it causes openReport() to be called too frequently, creating the flickering issue.

Suggested fix approach: The useEffect should be refactored to:

• Only call openReport() when necessary for the specific scenario
• Add a condition to check if we are actually transitioning from multiple transactions to one transaction
• Or use a different mechanism to handle the transaction thread creation without triggering unnecessary report refreshes