Duplicate Expensify Card transactions appear on draft reports in New Expensify staging

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs reproduction (Reproduction blocked)
Reproducible in production?: Needs reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @sakluger
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Have a draft report containing Expensify Card transactions that have already settled/posted.
2. Open the report in New Expensify staging.
3. Observe the transaction list.

Expected Result:

Once a card transaction posts/settles, the pending version should be removed and only the posted transaction should remain on the report.

Actual Result:

Both the pending and posted versions of each transaction remain visible on the draft report, causing duplicate expense entries.
The same report viewed in Classic shows only the posted transactions.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @KioCoan

[melvin-bot]

Triggered auto assignment to @cead22 (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: This is a backend/internal issue, not an App bug. New Expensify renders every transaction Onyx assigns to a report — it has no client-side logic to hide a pending Expensify Card transaction once its posted counterpart arrives, and it never has. So when both the pending and posted versions of a card transaction are present in Onyx for the same report, both render as separate rows. Classic shows only the posted one because the two clients build their transaction lists differently. The duplicate must be eliminated upstream (the pending transaction needs to be removed/replaced when it settles), which is a server-side responsibility. A separate internal investigation is needed.

Recommended next step: Because the fix is outside the App repo, this should be escalated to an internal engineer on the Expensify Card / settlement side rather than fixed here. It is also worth re-evaluating whether this should block the App deploy — no App-side dedup logic exists to have regressed, so an App PR in this release is an unlikely culprit.

Investigation details (App-side ruled out)

App data flow, from Onyx to the rendered list:

1. The derived value at reportTransactionsAndViolations.ts:99 keys each transaction into the report purely by transactionID. No status comparison, no amount/merchant matching, no "remove sibling pending" step — every transaction with a reportID is included.
2. The report view consumes that via getAllNonDeletedTransactions (MoneyRequestReportView.tsx:127).
3. The only filter applied (MoneyRequestReportUtils.ts:88-107) is on the Onyx optimistic-delete flag (pendingAction === DELETE) and deleted IOU actions — not on transaction.status.
4. isPending (TransactionUtils/index.ts:1358) is only used to gate Submit/Approve/Pay buttons, never to filter the rendered transaction list.

A repo-wide search found no field or helper that links a pending card transaction to its posted counterpart and removes one (originalTransactionID belongs to the unrelated Split/Merge features; transaction.posted is only a date string used for formatting). Conclusion: the App faithfully shows whatever Onyx says belongs to the report, so the duplicate originates upstream.

Alternative explanations considered: (a) A broken App dedup filter — ruled out, none ever existed. (b) The optimistic pendingAction: DELETE not being set on the pending row when it settles — this is the only client-side gate, but setting it is driven by the backend's Onyx update, so this still resolves to the server side.

To confirm with logs (needs IDs not present in this report): inspect the Onyx update for the affected report when the posted transaction arrived — does the backend null out / clear the pending transactionID, or are both transactions left attached to the same reportID?

Caveat: Reproduction is blocked and no reportID/accountID was provided, so the exact upstream mechanism is not yet confirmed with production data. Confidence that the fix is not in App: high. Confidence on the precise backend cause: medium.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis. Since the root cause is in backend/internal code, this can't be implemented as an App PR — please escalate to an internal engineer with card/settlement access.

[OSBotify]

🔍 Investigation Summary

Classification: Needs further investigation (likely Backend bug or pre-existing issue)
Causing PR: None identified with confidence (Low confidence)
Related Issues: N/A

Recommendation: NEEDS INVESTIGATION

The root cause cannot be attributed to a specific App PR from the current staging checklist with confidence. The issue may be a pre-existing behavioral difference between NewDot and Classic, or a backend-side problem with how the API marks pending card transaction actions for NewDot.

Assigned: @sakluger (issue reporter) — no causing PR identified, tagging for additional reproduction steps
Labels: No label changes made. DeployBlockerCash is retained pending reproduction confirmation.

📋 Detailed Analysis

Evidence

• The issue reports that both the pending and posted versions of settled Expensify Card transactions appear on a draft report in NewDot, while Classic correctly shows only the posted version.
• No version number was provided in the issue.
• Reproduction status is "Needs reproduction (Reproduction blocked)" — the bug has not been confirmed on staging.
• The issue was filed on 2026-06-11, the same day the staging deploy checklist was created.

Investigation of staging PRs

Every PR in the StagingDeployCash checklist (v9.4.5-1) was reviewed for relevance. None of the PRs touch the specific code path responsible for deduplicating pending vs. posted Expensify Card transaction actions:

• PR Inline PureReportActionItem into ReportActionItem #92925 (Inline PureReportActionItem into ReportActionItem): Confirmed as a structural refactor with no functional changes to visibility logic.
• PR Display forwarded approval memo in report actions #92877 (Display forwarded approval memo): Only adds a new getForwardedReportActionMessage function; no changes to shouldReportActionBeVisible or isVisiblePreviewOrMoneyRequest.
• PR Part 2: Remove Onyx.connect() for the key: ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS in src/libs/actions/IOU.ts #92896, migrate money request part 2 #92161, refactor isReportInGroupPolicy to use policy from useOnyx part 1 #92340, [Submit] Payment received for submitters (Wave 3) #91753: Touch ReportUtils.ts or ReportActionsUtils.ts but only for policy-type checks, navigation routes, and transaction submission logic — none affect card transaction deduplication.

Verification

The relevant code path for filtering pending card transactions is:

1. shouldReportActionBeVisible in src/libs/ReportActionsUtils.ts — controls which report actions are shown.
2. isVisiblePreviewOrMoneyRequest (line 1511) — filters out deleted money request actions and ReportPreview actions with shouldShow: false. Notably, this function does not check shouldShow === false for IOU/money request actions — only for ReportPreview actions.
3. useReportTransactions hook (src/hooks/useReportTransactions.ts) — returns all transactions for a report by reportID without filtering by status (Pending vs Posted).

Root Cause Hypothesis

When an Expensify Card transaction settles/posts, the backend should either:

• Set shouldShow: false on the pending transaction's IOU report action (so NewDot hides it), OR
• Mark the pending transaction's action with pendingAction: DELETE

If the backend relies on the shouldShow: false flag but isVisiblePreviewOrMoneyRequest in NewDot does not honor shouldShow === false for IOU/money request actions (unlike how it does for ReportPreview actions), both the pending and posted actions would be displayed.

This could be:

1. A pre-existing NewDot bug — NewDot never properly filtered pending card transaction IOU actions via shouldShow, but this was only noticed now.
2. A backend bug — the API is not sending the correct shouldShow: false or pendingAction: DELETE signals for pending card transaction actions when accessed via NewDot's API calls (while Classic's different API flow handles it correctly).

Neither hypothesis points to a specific App PR from this staging checklist as the introduction point.

Recommended next steps

1. Confirm whether this bug is reproducible on staging (v9.4.5-1) — the issue currently says reproduction is blocked.
2. If reproducible: check whether the pending card transaction's IOU reportAction in Onyx has shouldShow: false set. If yes, it's an App bug in isVisiblePreviewOrMoneyRequest. If no, it's a backend bug.
3. Check if this is reproducible on current production (v9.4.4-x) — if it is, this is a pre-existing issue, not a regression from this staging release, and DeployBlockerCash should be reconsidered.