Expense - Expense does not appear in merge expense list after changing amount to non-zero

[lanitochka17]

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.3-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: #79197
Email or phone of affected tester (no customers): applausetester+sjdiossndjois2jd@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Search

Action Performed:

Precondition:

• Log in with Expensifail account.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses with 0.00 amount.
4. Open expense report.
5. Open any expense from Step 3.
6. Change the amount to non-zero.
7. Open the other 0.00 expense.
8. Click More > Merge.

Expected Result:

The non-zero expense should appear in merge expense list because the expense amount is no longer 0.00.

Actual Result:

The non-zero expense does not appear in merge expense list after changing the amount to non-zero.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7050353_1768500392122.9.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @stephanieelliott (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: #79197 - "[BETA] Allow zero-amount expenses - ROUND 5" by @Gonals (High confidence)
Related Issues: N/A

Recommendation: ROLL FORWARD

This bug is behind the zeroExpenses beta and affects a specific edge case in the merge expense flow. A targeted fix to refresh the eligible transactions list would be simpler and safer than reverting, as reverting would lose the entire zero-amount expenses feature which has extensive testing.

Labels: No label changes needed - keeping DeployBlockerCash as this is a Frontend bug affecting the App

📋 Detailed Analysis

Evidence

PR #79197 introduced support for zero-amount expenses (behind the zeroExpenses beta flag). The merge expense functionality includes a check in src/libs/MergeTransactionUtils.ts (lines 396-399) that prevents merging two $0 transactions:

// Do not allow merging two $0 transactions
if (getAmount(transaction1, false, false) === 0 && getAmount(transaction2, false, false) === 0) {
    return false;
}

Verification

The bug occurs because:

1. Cached eligible transactions list: When opening the merge expense page, MergeTransactionsListContent.tsx (lines 48-55) calls getTransactionsForMerging() which populates an eligibleTransactions array. This array is cached and only fetched once:

   useEffect(() => {
       // If the eligible transactions are already loaded, don't fetch them again
       if (Array.isArray(mergeTransaction?.eligibleTransactions) || !targetTransaction) {
           return;
       }
       getTransactionsForMerging({...});
   }, [transactions, isOffline, mergeTransaction?.eligibleTransactions, ...]);

2. Stale data in eligibility check: When you edit a transaction to change its amount from 0.00 to non-zero, the transaction in Onyx is updated. However, the eligibleTransactions array stored in the merge transaction data is NOT refreshed.

3. Filter uses stale data: When you return to the merge list, areTransactionsEligibleForMerge() checks the cached transaction objects in eligibleTransactions, which still have the old 0.00 amounts. Since both cached transactions show 0.00, the check at line 397 returns false, excluding the transaction from the merge list.

Root Cause

The merge flow caches the eligible transactions list and does not subscribe to transaction updates. When a transaction is edited, the cache becomes stale, causing incorrect filtering based on outdated transaction data.

Suggested Fix

Add logic to either:

1. Clear the merge transaction data (including eligibleTransactions) when any transaction is edited
2. Re-fetch eligible transactions when returning to the merge list page if transactions have been updated
3. Use real-time transaction data from Onyx instead of the cached eligibleTransactions array for the eligibility check