[Due for payment 2026-08-31] Report - WS avatar disappears when moving expense opened via growl to another report offline

@situchan

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

Version Number: 9.4.58-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: #96496
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Money Requests

Action Performed:

Prerequisite: Account has a workspace.

Open the Expensify app.
Turn off internet connection.
Create a manual expense and submit it to workspace.
Tap on "View" on the displayed growl.
Tap on "More" > "Move to Report" > "Create Report"
Note that after expense is moved, workspace avatar disappears from report header.

Expected Result:

Workspace avatar should remain visible on report header after moving expense to a new report on the same workspace while in offline mode.

Actual Result:

Workspace avatar disappears from report header after moving an expense opened via growl to a new report while in offline mode.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7239816_1787376044153.Growl_10.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7239816

Issue Owner

Current Issue Owner: @situchan

@mountiny

@mountiny recently merged #96496, but they are OOO right now, so I'll auto-assign someone else.

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

@mollfpr

Triggered auto assignment to @mollfpr (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

👋 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:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@mountiny

@mountiny @situchan you have been assigned to this deploy blocker because you reviewed the offending PR: #96496

@mhawryluk

@mhawryluk you have been assigned to this deploy blocker because you authored the offending PR: #96496

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

@mhawryluk

🔍 Investigation Summary

Classification: Frontend bug (fix belongs in Expensify/App)
Causing PR: #96496 - "Confirm new expenses with a “View” toast instead of scrolling to and highlighting the row" by @mhawryluk (High confidence it is the responsible/entry PR; Medium confidence on the exact failing line)
Related Issues: N/A

Recommendation: ROLL FORWARD

The growl flow is otherwise working and shipping fine; this is a narrow offline-only, multi-step edge case (missing workspace avatar) that should be fixed forward rather than reverting a large, cohesive feature PR (which would also re-introduce the removed row-highlighting behavior). A full revert is the fallback if a quick targeted fix can't be found.

Assigned: @mhawryluk (PR author), @mountiny and @situchan (approving reviewers) — already assigned to this issue, no change needed.
Labels: No change. Frontend bug → DeployBlockerCash stays (App deploy is blocked). No DeployBlocker (web) label is present, so nothing to remove. Staging-only / N/A prod, so the label must remain.

📋 Detailed Analysis

Evidence

PR Confirm new expenses with a “View” toast instead of scrolling to and highlighting the row #96496 is in the current StagingDeployCash #99230 and introduces the exact "Expense added" growl + "View" action that is a mandatory step in the repro (step 4: "Tap on View on the displayed growl"). This is the "new feature" that explains why the bug is staging-only / N/A in prod.
The repro is only reachable through the growl "View" path added by this PR. Opening the same expense the normal way (from its chat) does not go through the growl's optimistic-thread construction, which is why QA routed the repro through the growl specifically.
The bug is a client-side rendering/Onyx-state problem (a workspace/subscript avatar failing to resolve), which is squarely a frontend concern — no server error is involved.

Verification

Growl "View" handler that builds/opens the optimistic transaction thread: src/components/ExpenseAddedGrowl.tsx#L126-L149. It resolves the thread with transaction?.transactionThreadReportID ?? iouAction?.childReportID and then either:
- setOptimisticTransactionThread (shallow Onyx.merge of a handful of fields, forcing type: CHAT), or
- createTransactionThreadReport (generates a brand-new optimistic thread reportID and openReports it while offline).
The report header avatar is rendered by AvatarWithDisplayName via ReportActionAvatars, and the workspace (subscript) avatar is resolved from the report's policyID (usePolicy(report?.policyID)). If policyID doesn't resolve to a real workspace, the workspace avatar disappears.
The move-to-report onyx builder writes the moved thread's policyID here: src/libs/actions/Transaction.ts#L1564-L1578.

Root Cause

When the expense is opened via the growl "View", PR #96496 builds an optimistic transaction thread (createTransactionThreadReport / setOptimisticTransactionThread). Offline, this optimistic thread is only loosely linked to its parent IOU action / destination report.

The user then does More → Move to Report → Create Report, which runs getChangeTransactionsReportOnyxData and re-writes the transaction thread report:

// src/libs/actions/Transaction.ts:1571-1577
value: {
    parentReportID: targetReportID,
    parentReportActionID: optimisticMoneyRequestReportActionID,
    policyID: reportID !== CONST.REPORT.UNREPORTED_REPORT_ID && newReport ? newReport.policyID : CONST.POLICY.ID_FAKE,
    participants: isUnreported && shouldRemoveOtherParticipants ? {[accountID]: participants?.[accountID]} : participants,
},

The critical line is src/libs/actions/Transaction.ts#L1575: policyID falls back to CONST.POLICY.ID_FAKE ('_FAKE_') whenever newReport is not resolvable at that moment. _FAKE_ is not a real policy, so usePolicy(report.policyID) in the header returns nothing and the workspace subscript avatar disappears. The childReport/newReport linkage that feeds this branch is exactly the state that the growl's optimistic-thread path leaves incomplete while offline, which is why the symptom only appears via the growl entry point offline (online, OpenReport/CreateAppReport reconciles the real policyID and the avatar returns).

Suggested targeted fix (for the assignees to confirm): ensure the growl-built optimistic transaction thread carries a real policyID (and complete participant/parent linkage) so the subsequent offline move-to-report doesn't fall back to CONST.POLICY.ID_FAKE; alternatively, harden Transaction.ts:1575 to preserve the thread's existing policyID instead of ID_FAKE when newReport is momentarily unresolved offline.

Confidence note: High confidence that #96496 is the responsible/entry PR (it is the new feature and a required repro step). Medium confidence on the exact failing line because the ID_FAKE fallback lives in move-to-report code that #96496 did not modify — #96496 exposes it via the optimistic thread it creates. The author (@mhawryluk), who knows this optimistic-thread path, should confirm which of the two fix locations is correct before landing.

Issue is not reproducible on Xiaomi Poco F5 / Android 13 in v9.4.59-1

1000220664.mp4

@situchan

@situchan

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.59-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

[CP Staging] Revert "Confirm new expenses with a “View” toast instead of scrolling to and highlighting the row" #99277

If no regressions arise, payment will be issued on 2026-08-31. 🎊

The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]

@MelvinBot

The root cause existed in production.

Fixed by +2 lines in getChangeTransactionsReportOnyxData (Transaction.ts), adding chatReportID to the optimistic thread update.

I verified #96496 (v1) never touched that function — its only Transaction.ts change was renaming the Onyx helper — and chatReportID was absent there at the merge base. The growl supplied a new entry point; the defect was in shared move-to-report code.

cc: @MelvinBot

You're right. I checked, and my earlier analysis was wrong on both the causing PR and the failing field.

Confirm new expenses with a “View” toast instead of scrolling to and highlighting the row changed only one thing in Transaction.ts: it renamed mergeTransactionIdsHighlightOnSearchRoute to mergeExpenseAddedGrowlTransactionIDs. It never touched getChangeTransactionsReportOnyxData.
At its merge base (650d353), Transaction.ts has no chatReportID anywhere. The optimistic thread update set only parentReportID, parentReportActionID, policyID, and participants (Transaction.ts:1571-1576).
The fix, 208954f, adds chatReportID to both the new and old thread updates. It did not change the CONST.POLICY.ID_FAKE fallback I flagged.

So the defect lived in shared move-to-report code that was already in production. The growl only added a new way to reach it.

One clarification for the record: the PR linked as the fix above, [CP Staging] Revert "Confirm new expenses with a “View” toast…", was a revert. The actual code fix shipped in Confirm new expenses with a “View” toast instead of scrolling to and highlighting the row v2.

Navigation Menu

Repository navigation

[Due for payment 2026-08-31] Report - WS avatar disappears when moving expense opened via growl to another report offline #99258

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

🔍 Investigation Summary

Recommendation: ROLL FORWARD

Evidence

Verification

Root Cause

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-08-31] Report - WS avatar disappears when moving expense opened via growl to another report offline #99258

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Aug 22, 2026

applause-bot commented on Aug 22, 2026

melvin-bot commented on Aug 22, 2026

github-actions commented on Aug 22, 2026

melvin-bot commented on Aug 22, 2026

melvin-bot commented on Aug 22, 2026

melvin-bot commented on Aug 22, 2026

MelvinBot commented on Aug 22, 2026

🔍 Investigation Summary

Recommendation: ROLL FORWARD

Evidence

Verification

Root Cause

m-natarajan commented on Aug 24, 2026

melvin-bot commented on Aug 24, 2026

situchan commented on Oct 4, 2026

MelvinBot commented on Oct 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions