[Due for payment 2026-04-30] Avatar opens not here page, confirm page loads infinitely when submit undeleted expense offline

[jponikarchuk]

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

Action Performed:

Precondition:

• Have a deleted expense.

1. Go to staging.new.expensify.com
2. Go to Reports > Expenses.
3. Click filters > Status > select Deleted > Apply.
4. Go offline.
5. Select the expense via checkbox.
6. Click dropdown button > Undelete.
7. Go to self DM.
8. Open the undeleted expense.
9. Click on the report header.
10. Click avatar.
    → Not here page opens.
11. Close the avatar view.
12. Click Submit it to someone.
13. Select workspace chat.
    → Confirm page loads infinitely.

Expected Result:

In Step 10, fallback avatar should not be clickable.
In Step 13, confirm page will not load infinitely.

Actual Result:

In Step 10, fallback avatar opens not here page.
In Step 13, confirm page loads infinitely.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @rojiphil

[melvin-bot]

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

[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: #86938 - "Deleted transactions on search V2" by @jnowakow (High confidence)
Related Issues: None

Recommendation: REVERT

PR #86938 introduced the undelete-transaction-from-search feature and the two reported symptoms both stem directly from that PR. Reverting it cleanly removes both regressions without touching unrelated code.

Assigned: @jnowakow (PR author), @rojiphil (approving reviewer), @luacmartins (approving reviewer)
Labels: DeployBlockerCash kept (frontend App PR is the cause). No label changes made.

Detailed Analysis

Evidence

The melvin-bot automatically assigned this issue to the PR author of #86938. The issue is reproducible on staging only (marked "N/A" for production, described as a "new feature that does not exist in prod"), which is consistent with a staging-only PR introducing a regression.

The bug report describes two separate symptoms after undeleting an expense offline via the search results list:

Symptom 1 (Step 10): Fallback avatar is clickable and opens "Not here" page.
PR #86938 modifies TransactionListItem.tsx to set shouldShowUserInfo={!isDeletedTransaction && !!transactionItem?.from} — meaning the user info row is hidden for deleted transactions. However, after the optimistic undelete write, the transaction reportID changes from TRASH_REPORT_ID to the real report, but participant data in Onyx may be incomplete while the request is in-flight. The from field may reference a participant whose personal details are not fully loaded, causing the avatar to render as a fallback that is still pressable and navigates to a "Not here" page.

Symptom 2 (Step 13): Confirm page loads infinitely after selecting a workspace.
PR #86938 significantly refactors changeTransactionsReport in Transaction.ts to handle deleted transactions. When isDeletedExpense is true, oldIOUAction is forced to undefined. A synthetic IOU action is constructed and pushed to REPORT_ACTIONS, but without a valid childReportID. The transaction is also merged with data spread from incomplete search result fields. Downstream flows (submit-to-workspace confirm page) depend on fully-populated transaction and report-action data. After the optimistic undelete write while offline, the changeTransactionsReport call for submitting to a workspace finds this stale/incomplete state, causing the confirm page loading spinner to never resolve.

The new useUndeleteTransactions hook (added in this PR) calls changeTransactionsReport without a reportID, defaulting to CONST.REPORT.UNREPORTED_REPORT_ID. After optimistic success, the transaction appears as unreported in self-DM. When the user then selects "Submit it to someone" and picks a workspace, a second changeTransactionsReport call is made, which fails to find a valid transaction thread (childReportID) because the synthetic IOU action created during undelete had none.

Verification

Files modified by PR #86938 that are directly implicated:

• src/hooks/useUndeleteTransactions.ts (new file) — the hook driving the undelete flow
• src/libs/actions/Transaction.ts — heavily refactored changeTransactionsReport to handle isDeletedTransaction
• src/components/Search/SearchList/ListItem/TransactionListItem.tsx — avatar/user info visibility changes for deleted transactions
• src/libs/actions/Search.ts — handleActionButtonPress now dispatches UNDELETE action type
• src/components/Search/SearchList/index.tsx — wires handleUndelete callback through the list

The PR merge date (2026-04-15T15:35:22Z) aligns with the bug first being caught in this staging cycle (version 9.3.60-0). The issue body itself links PR #86938 as the source under "regression testing."

Root Cause

The new undelete flow performs an optimistic Onyx write that spreads incomplete transaction data from search results into the TRANSACTION collection, and creates a synthetic IOU report action without a valid childReportID. Downstream flows (avatar rendering, submit-to-workspace confirm page) depend on fully-populated transaction and report-action data that is not present after the optimistic undelete write while offline.

[MelvinBot]

Proposal

What is the root cause of that problem?

When a deleted transaction (reportID '-1') is undeleted, changeTransactionsReport explicitly sets oldIOUAction = undefined for deleted expenses since the original IOU action was cleaned up during deletion. This causes two downstream failures:

Bug 1 — Avatar opens "Not here" page: Since oldIOUAction is undefined, newIOUAction.childReportID is also undefined (line 1290/1320), so a brand-new transaction thread is created via buildTransactionThread. Because newIOUAction has no actorAccountID, Number(undefined) yields NaN which is filtered out (line 8780), leaving only the current user as participant. The thread is built with ownerAccountID = OWNER_ACCOUNT_ID_FAKE (0) and policyID = undefined (no moneyRequestReport is passed for unreported destinations at line 1323). This incomplete thread causes navigation to a "Not here" page when clicking the avatar.

Bug 2 — Confirm page loads infinitely: On line 1068, linkedTrackedExpenseReportAction is only set when oldIOUAction is truthy — so for undeleted transactions it's never set. Additionally, isUnreportedExpense is false for deleted transactions (reportID '-1' ≠ '' or '0'), so the track expense actionable whisper is never looked up. When the user clicks "Submit to someone", the submit flow lacks the required whisper action and linked IOU action data. Combined with IOURequestStepConfirmation showing a permanent loading indicator when transaction.originalCurrency is truthy (an online-only update that never resolves offline), the confirm page loads infinitely.

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

In changeTransactionsReport (Transaction.ts), when handling deleted expenses (isDeletedExpense = true):

1. Set actorAccountID on the new IOU action — use the current user's accountID so buildTransactionThread generates a valid participant list (instead of NaN).

2. Always set linkedTrackedExpenseReportAction on the optimistic transaction data regardless of whether oldIOUAction existed (line 1068). Change the condition from oldIOUAction ? {linkedTrackedExpenseReportAction: newIOUAction} : {} to always include it.

3. Fix the isUnreportedExpense check for deleted transactions — line 1228 should also check isDeletedExpense so that the actionable whisper is created for undeleted transactions moving to unreported state. Change to: const trackExpenseActionableWhisper = (isUnreportedExpense || isDeletedExpense) ? getTrackExpenseActionableWhisper(...) : undefined;

What alternative solutions did you explore? (Optional)

An alternative would be to reconstruct the full oldIOUAction from transaction data for deleted expenses instead of using undefined, effectively re-synthesizing all the fields the original IOU action would have had. However, this is more complex and error-prone since the original data is gone. The targeted fixes above address each symptom directly at the point of failure.

Investigation details

Key code flow:

1. useUndeleteTransactions → changeTransactionsReport with no newReport (destination = UNREPORTED '0')
2. isDeletedExpense = true → oldIOUAction = undefined (line 1019)
3. newIOUAction spread from undefined has no actorAccountID, no childReportID (lines 1037-1052)
4. No existing childReportID → new thread created via buildTransactionThread(newIOUAction, undefined) (line 1323)
5. Number(undefined) = NaN, filtered by Boolean → single-participant thread (line 8780)
6. Thread gets fake ownerAccountID and no policyID → "Not here" on avatar click
7. linkedTrackedExpenseReportAction not set (line 1068, condition is false)
8. isUnreportedExpense is false for reportID '-1' → no whisper (line 1228)
9. Submit flow missing required data + originalCurrency check → infinite loading (line 1319)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.