Web - Export - Download PDF cancels unexpectedly when resizing the browser

[applause-bot]

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

---

Version Number: v9.4.46-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/66874020/folder/14961849/116946224/1615343510?sort=%2Bidentifier
Email or phone of affected tester (no customers): applausetester+exportemplate@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/Chrome
App Component: Chat Report View

Action Performed:

1. Log in to applausetester+exportemplate@applause.expensifail.com
2. Navigate to Spend > Reports
3. Bulk select all reports -> x selected -> Download as PDF
4. While the Download as PDF process - Rezice the browser to a narrow view

Expected Result:

Web keeps the download process

Actual Result:

Web cancels the download process

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7221571_1785391233129.Download_PDF.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7221571

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082847195879366371
• Upwork Job ID: 2082847195879366371
• Last Price Increase: 2026-07-30

[applause-bot]

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The backend export is not actually cancelled — the client just loses its handle to the in-flight download when the browser crosses the narrow/wide layout breakpoint.

When you bulk-select reports and pick Download as PDF, the multi-report path calls exportReportsToPDF() then trackExport(exportID). trackExport is just setActiveExportID — an ephemeral useState inside useExportDownloadStatusModal, which lives inside SearchBulkActionsButton. The actual "download when ready" useEffect lives inside the ExportDownloadStatusModal that this state renders.

Resizing the browser flips useResponsiveLayout().shouldUseNarrowLayout, and SearchPage hard-swaps its subtree with a ternary: shouldUseNarrowLayout ? <SearchPageNarrow/> : <SearchPageWide/>. Each branch mounts its own SearchBulkActionsButton → useExportDownloadStatusModal. So on resize the current button unmounts (destroying activeExportID) and a fresh one mounts with activeExportID === undefined. There is no mount-time recovery effect that re-adopts a PREPARING export from Onyx, so:

• The status modal disappears (this is what looks like a "cancel").
• When the backend flips the Onyx entry EXPORT_DOWNLOAD_<exportID> to READY, no component is left watching it, so the file is never downloaded.

The EXPORT_DOWNLOAD_<exportID> Onyx entry itself survives the remount (it's collection state, not component state) — only the React tracking of it is lost. The stale entry lingers until clearStaleExportDownloads() runs on the next app/auth init.

Evidence (SHA c7d4886)

• Bulk trigger (multi-report → exportReportsToPDF + trackExport): src/hooks/useSearchBulkActions.ts:2065-2089
• Export action writes Onyx EXPORT_DOWNLOAD_<exportID> = {state: PREPARING}: src/libs/actions/Export.ts:80-103
• Tracking state is ephemeral useState, no recovery effect: src/hooks/useExportDownloadStatusModal.tsx:27-53
• The auto-download useEffect lives inside the modal, keyed on READY: src/components/ExportDownloadStatusModal.tsx:55-90
• The remount cause — narrow/wide ternary: src/pages/Search/SearchPage.tsx:145-170

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

Make the export tracking survive the layout swap so a remount doesn't drop it. Either:

1. Recover on mount (smaller change): In useExportDownloadStatusModal, add an effect that, on mount, scans the EXPORT_DOWNLOAD Onyx collection for any entry still in PREPARING/not-yet-downloaded and re-adopts it into activeExportID. This makes the newly-mounted button pick the in-flight export back up after a resize. Apply the same recovery to the single-report path (setPdfReportID/setIsPdfModalVisible in the same hook), which is fragile the same way.

2. Lift the state (more robust): Host the export-tracking state and the ExportDownloadStatusModal above the SearchPageNarrow/SearchPageWide ternary (e.g. in SearchPage or a shared context/provider) so switching layouts no longer unmounts it.

Option 2 is cleaner long-term; option 1 is the minimal targeted fix.

What alternative solutions did you explore? (Optional)

Rendering the modal from a global/root provider so no Search-page layout change can unmount it.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97483) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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