Receipt PDF download hangs indefinitely and expense report fails to load after approval

[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 (Unable to reproduce)
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: @Kel-Expensify
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open an expense report in New Expensify.
2. Update the expense report name.
3. Approve the expense report.
4. Attempt to Download PDF for the receipt.
5. Observe the behavior.
6. Close and reopen New Expensify.
7. Search for the approved expense report using the submitter's name.
8. Open the report and observe the loading behavior.

Expected Result:

The receipt PDF should download successfully.
After reopening the application, the expense report should load normally when searched.

Actual Result:

Downloading the receipt PDF remains stuck on an indefinite loading spinner.
After reopening the app, opening the expense report also results in an indefinite loading spinner, preventing the report from loading.

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082203304791124964
• Upwork Job ID: 2082203304791124964
• Last Price Increase: 2026-07-28

Issue Owner

Current Issue Owner: @mjasikowski

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Issue Analysis

Root Cause (medium confidence — both symptoms are backend/runtime-driven, so they need production logs to confirm):

The two symptoms are separate mechanisms, but both are "the App is waiting on a server-pushed Onyx update that never arrives," which is exactly why this is Unable to reproduce — it depends on runtime queue/sync state, not a deterministic code path.

1. Download PDF spinner spins forever. The App-side flow is self-consistent and cannot itself stall other than by never receiving the backend update. exportReportToPDF optimistically SETs nvp_expensify_report_PDFFilename_{reportID} to null (spinner on) and there is no successData — the filename must arrive via a backend-pushed Onyx update. The modal only stops spinning when that key becomes a real filename (success) or 'error' (failure). If the server generates/queues the PDF but never pushes the filename update (and no failure fires), the spinner hangs indefinitely with no client-side timeout.

2. Report stuck loading after reopen. The report-open skeleton is driven by isLoadingInitialReportActions, stored in a RAM-only Onyx key (reportLoadingState_) that resets to true on every app restart. It is cleared only by OpenReport's success/failure data. The most plausible stuck path: after an approval (which pushes new report actions), the client falls behind on Onyx update IDs, so SaveResponseInOnyx defers applying OpenReport's response and pauses the queue pending reconciliation. If that reconciliation never completes, the flag stays true forever → permanent skeleton (and ReportNotFoundGuard keeps isLoading true, so you get a spinner rather than a "not found" page). A secondary path: for a money report with total !== 0, shouldWaitForTransactions stays true until transactions load, so missing/unsynced transaction data also holds the skeleton up.

Recommended next steps: The actual fix for both symptoms is outside the App repo (server-side PDF generation for #1; the Onyx-update sync/reconciliation for #2), so this should be escalated to an internal engineer for backend/log investigation rather than fixed in App. Production logs for the affected reportID would confirm which path fires — see the queries below.

Investigation details & evidence

Commit: 49c0d8e056372dda5cbabcfd413c0306c17d726b

Download PDF (symptom 1):

• Trigger: useExportActions.ts:250-266 → opens modal + fires exportReportToPDF.
• Action: Report/index.ts:6327-6356 — optimistic SET to null, failure MERGE 'error', no successData. downloadReportPDF only fetches an already-generated file; it does not generate the PDF.
• Spinner logic: ReportPDFDownloadModal.tsx:56-121 — hasFinishedPDFDownload is true only when the filename key is set and not 'error'; otherwise ActivityIndicator renders. No timeout.
• Note the approval/submit-via-PDF flow reuses the same NVP key (ReportWorkflow.ts:1678-1692) — worth checking whether the just-completed approval left that key in a state that interferes with the subsequent Download PDF.

Report load (symptom 2):

• Skeleton condition: MoneyRequestReportView.tsx:156-215.
• shouldWaitForTransactions: MoneyRequestReportUtils.ts:145-164 — stays true when total !== 0 and no transactions loaded.
• RAM-only flag: RAM_ONLY_REPORT_LOADING_STATE at ONYXKEYS.ts:876, default {isLoadingInitialReportActions: true} → resets on restart.
• Cleared only by OpenReport success/failure: Report/index.ts:1584-1654.
• Deferred-update path (most plausible): SaveResponseInOnyx.ts:42-53 pauses the queue on an update-ID gap; if reconciliation never completes, the flag never clears.
• Not-found guard keeps the spinner (not a 404) while the flag is stuck: ReportNotFoundGuard.tsx:45-73.
• The report-name edit (Report/index.ts:3655-3704) writes only reportName/pendingFields and has no conflict resolver, so it cannot cancel OpenReport — it appears to be coincidental context in the repro steps rather than a direct cause.

Alternative explanations considered: (a) transaction data never syncing while total !== 0 (holds skeleton independent of the request); (b) fetchReport early-returning so no OpenReport ever runs to clear the RAM default. Logs disambiguate these from the update-gap path.

Logs that would confirm (for the affected reportID/account):

• ExportReportToPDF for the report — did it succeed but return no onyxData for nvp_expensify_report_PDFFilename_{reportID}, or error/timeout without a failure jsonCode?
• OpenReport for the report — response jsonCode, and any [OnyxUpdateManager] gap / GetMissingOnyxMessages / shouldPauseQueue activity around it.
• [SequentialQueue] conflict-resolution or "Request failed too many times" entries for OpenReport.
• Whether the report has total !== 0 but zero synced transactions server-side.

---

Next Steps for Contributor+ team:
This looks like a backend/sync root cause (server-side PDF generation and Onyx update reconciliation), so it needs an internal engineer with log access to confirm before any code change — a client-side "implement this" fix isn't appropriate here.
To refine: @MelvinBot <your feedback>

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022082203304791124964

[mananjadhav]

I'll try to reproduce the issue.

[mukhrr]

@mananjadhav I can

97273-before.mp4

[mananjadhav]

@mukhrr Are you keen on posting a proposal for the same?

[mukhrr]

@mananjadhav sure!

[mukhrr]

But not sure I will be the first or not after Help Wanted, haha