You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expense - "Chat report" opens report with infinite loading when report is shared #104269
Version Number: 9.5.13-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:#103141 Email or phone of affected tester (no customers):[email protected] Issue reported by: Applause Internal Team Bug source: Exploratory - Significant User Experience Deterioration Device used: Mac 26.5 / Chrome App Component: Money Requests
Action Performed:
Go to staging.new.expensify.com
Go to workspace chat.
Create an expense.
Open the report.
Click Submit.
Click More > Share > Share report.
Enter User B email and share it to User B.
As User B, open search router.
Open "Chat report".
Expected Result:
Chat report will open the shared report or it should not appear in search router at all.
Actual Result:
Chat report opens report with infinite loading after being shared report.
👋 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.
Recommendation: revert. This is a new feature that isn't in production. The revert should apply cleanly. A fix-forward needs changes on both the server and the App.
Why it happens: After a share, User B gets a report with only basic fields and the server's default name, "Chat Report." The not-found guard treats any report with a reportID as existing, so it never shows not-found. Opening the report doesn't load the data the screen needs, so it stays on the skeleton.
Its shareReport sends ShareReport with read/write permissions. It has no optimistic, success or failure data, so everything User B gets comes from the server: actions/Report/index.ts:7059-7067
Why it loads forever
The search router lists any accessible report that has a reportID, type and reportName: ReportUtils.ts:11114-11143. When nothing better is available, the name falls back to report.reportName: ReportNameUtils.ts:1406-1408. "Chat Report" is the server's default chat name.
ReportNotFoundGuard sets reportExists = !!reportID, so a partial report never reaches the not-found page: ReportNotFoundGuard.tsx:57-78
Not confirmed: Whether the partial entry is the shared expense report or its parent workspace chat. That depends on what the server returns. It decides where a fix-forward belongs, but it doesn't change the revert recommendation.
not from this PR, Classic shares on production do the same. the recipient can't open the workspace chat the report came from and the page keeps loading instead of showing not found. fix: #104291
Activity
applause-bot commentedon Oct 16, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/6689861d3d7183827f45128cc7008dac261987ac8b19bdc41b0d584375fce827
melvin-bot commentedon Oct 16, 2026
@mollfpr recently merged #103141, but they are OOO right now, so I'll auto-assign someone else.
melvin-bot commentedon Oct 16, 2026
Triggered auto assignment to @inimaga (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.github-actions commentedon Oct 16, 2026
👋 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:
melvin-bot commentedon Oct 16, 2026
@mollfpr @abzokhattab you have been assigned to this deploy blocker because you reviewed the offending PR: #103141
melvin-bot commentedon Oct 16, 2026
@allgandalf you have been assigned to this deploy blocker because you authored the offending PR: #103141
melvin-bot commentedon Oct 16, 2026
💬 A slack conversation has been started in #expensify-open-source
MelvinBot commentedon Oct 16, 2026
Deploy Blocker Analysis
Causing PR: [Payment due @abzokhattab] Add Share to the report More menu. It merged 2026-10-16 and shipped in 9.5.13-0 with no beta gate. Confidence: high.
Recommendation: revert. This is a new feature that isn't in production. The revert should apply cleanly. A fix-forward needs changes on both the server and the App.
Why it happens: After a share, User B gets a report with only basic fields and the server's default name, "Chat Report." The not-found guard treats any report with a
reportIDas existing, so it never shows not-found. Opening the report doesn't load the data the screen needs, so it stays on the skeleton.Investigation details
Why this PR and not another one
#103141 is the only PR on the Deploy Checklist: New Expensify 2026-10-16 that adds or touches report sharing. The bug only appears after "Share report," which this PR adds:
SHAREto the More menu of every expense report:ReportSecondaryActionUtils.ts:1174ReportUtils.ts:14130shareReportsendsShareReportwith read/write permissions. It has no optimistic, success or failure data, so everything User B gets comes from the server:actions/Report/index.ts:7059-7067Why it loads forever
reportID,typeandreportName:ReportUtils.ts:11114-11143. When nothing better is available, the name falls back toreport.reportName:ReportNameUtils.ts:1406-1408. "Chat Report" is the server's default chat name.ReportNotFoundGuardsetsreportExists = !!reportID, so a partial report never reaches the not-found page:ReportNotFoundGuard.tsx:57-78Not confirmed: Whether the partial entry is the shared expense report or its parent workspace chat. That depends on what the server returns. It decides where a fix-forward belongs, but it doesn't change the revert recommendation.
Other PRs checked: perf: scope reports parent hierarchy in useReportsParentHierarchy touches the report screen. It can't create a new "Chat report" entry for User B.
Revert conflicts: Two later staging PRs touch the same files, in separate code. Neither should conflict: Prevent removing the IOU sender and receiver from an expense thread and Add payment details billed to and billing receipt.
Next Steps: Reply with
@MelvinBot <your feedback>to refine this analysis.view run
abzokhattab commentedon Oct 17, 2026
I think its the same root cause as this issue flagged in the PR #103141 (comment)
also i am not able to reproduce .. the report doesnt show up in the search:
Screen.Recording.2026-10-17.at.02.36.08.mov
anyways i think this is a backend issue.
@allgandalf let me know what you think about this
allgandalf commentedon Oct 17, 2026
not from this PR, Classic shares on production do the same. the recipient can't open the workspace chat the report came from and the page keeps loading instead of showing not found. fix: #104291
mollfpr commentedon Oct 19, 2026
Agree with @allgandalf. Demoting from deploy blocker.