[$250] Bulk PDF export is unavailable when using Select all across reports

[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: 9.4.34-12
Reproducible in staging?: Y
Reproducible in production?: Y
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: @Getrudygidashang
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in to New Expensify as a workspace admin.
2. Navigate to Spend > Reports.
3. Bulk select reports
4. Click Select all to select all matching reports (not just the current page).
5. Click Selected > Export.
6. Observe the available export options.

Expected Result:

Download PDF should be available when using Select all, just as it is when using Select all on this page.

Actual Result:

The Download PDF option is not displayed after selecting Select all.
The option is only available when using Select all on this page.

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

Recording.3223.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077505864591597507
• Upwork Job ID: 2077505864591597507
• Last Price Increase: 2026-07-15

Issue Owner

Current Issue Owner: @lorretheboy

[MelvinBot]

Issue Analysis

Root Cause: When you choose Select all (all matching reports across pages), the bulk-actions menu is built by an early-return branch that returns only the Export option and nothing else — so it never reaches the code that adds Download as PDF. With Select all on this page, that branch is skipped and the PDF option is added normally.

The relevant code is src/hooks/useSearchBulkActions.ts:1662-1664:

if (areAllMatchingItemsSelected) {
    return [exportButtonOption];
}

The Download as PDF option is only pushed later, at useSearchBulkActions.ts:1915-1940, which is unreachable once the early return fires.

Why it's gated this way (not just an oversight): "Select all" doesn't load every matching report client-side — selectAllMatchingItems only flips areAllMatchingItemsSelected to true; selectedReports/selectedReportIDs still contain only the loaded page. CSV/integration export handles this by sending the search query to the backend with an empty reportIDList (useSearchBulkActions.ts:630-642), letting the server resolve all matches. PDF export has no such query path — exportReportsToPDF accepts only an explicit list of reportIDs. So PDF was excluded from the all-matching branch because it literally can't be handed the full set of IDs.

Recommended fix: Enabling parity requires a backend change — the PDF export command needs to accept a serialized search query (empty reportIDList) like CSV export does, so the server can render all matching reports. Once that exists, the App fix is to add the Download-as-PDF option inside the areAllMatchingItemsSelected branch and route it through the query-based path.

Because the core of this fix lives outside Expensify/App (the export command is backend), this needs an internal engineer with access to those repos to implement the query-based PDF export. I can't implement that from the App repo alone.

Investigation details & evidence chain

• Symptom: "Download PDF" absent under Select all (all matching), present under Select all on this page. Reproducible in staging & production — consistent with a deterministic code path, not a data/race issue.
• areAllMatchingItemsSelected is set purely by the "select all matching" toggle and does not enumerate report IDs.
• Early return at useSearchBulkActions.ts:1662 → menu = [exportButtonOption] only.
• PDF option push at useSearchBulkActions.ts:1915 is gated on isExpenseReportSearch && selectedReportIDs.length > 0 and sits after the early return, so it is skipped.
• CSV export's all-matching path (queueExportSearchWithTemplate with jsonQuery + empty reportIDList) is the pattern PDF would need to mirror.
• Alternative considered: a frontend-only fix that surfaces the PDF option and exports just selectedReportIDs. Rejected — it would silently export only the currently-loaded page rather than all matching reports, which is misleading.

---

Next Steps for Contributor+ team:
This one needs a backend change (query-based PDF export) before the App side can be wired up — please route to an internal engineer. Reply with @MelvinBot <feedback> to refine this analysis.

[samranahm]

Proposal

What is the root cause of that problem?

When a workspace admin selects reports on Spend > Reports and clicks "Select all" to select every matching report across pages (not just the current page), the "Selected > Export" menu drops the "Download PDF" option, even though it appears when only the current page is selected.

This happens because the bulk report actions in Search are wired through per selection handlers that operate on the concrete set of selected report keys currently held on the page. BulkDuplicateReportHandler shows this pattern, receiving selectedReports and turning them into an action:

App/src/components/Search/BulkDuplicateReportHandler.tsx

Lines 23 to 31 in c81c4b7

	function BulkDuplicateReportHandler({selectedReports, allReports, searchData, onHandlerReady}: BulkDuplicateReportHandlerProps) {
	const handleDuplicateReports = useBulkDuplicateReportAction({selectedReports, allReports, searchData});
	useEffect(() => {
	onHandlerReady(handleDuplicateReports);
	}, [handleDuplicateReports, onHandlerReady]);
	return null;
	}

When "Select all matching" is toggled, the Search context no longer tracks individual selectedReports keys; it tracks a "select all across results" flag plus the search query. The export options builder in the Search selection header then computes the available export actions from the concrete selected keys. Because the PDF export path expects a finite list of report IDs (which is empty in the select-all-across state), the code that constructs the export dropdown treats "Download PDF" as not applicable and omits it, while CSV style exports that can accept the query stay available. That gap is what the user sees: PDF export is present for "select all on this page" but disappears for "select all across reports".

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

1. In the Search selection header logic that builds the "Export" dropdown options (the same layer that feeds handlers like BulkDuplicateReportHandler), stop gating the "Download PDF" entry on a non-empty concrete selectedReports list. Instead, include the PDF option whenever there is a valid selection, including the select-all-across-results state.

App/src/components/Search/BulkDuplicateReportHandler.tsx

Lines 23 to 31 in c81c4b7

	function BulkDuplicateReportHandler({selectedReports, allReports, searchData, onHandlerReady}: BulkDuplicateReportHandlerProps) {
	const handleDuplicateReports = useBulkDuplicateReportAction({selectedReports, allReports, searchData});
	useEffect(() => {
	onHandlerReady(handleDuplicateReports);
	}, [handleDuplicateReports, onHandlerReady]);
	return null;
	}

2. When the select-all-across-results flag is active, pass the current search query to the PDF export action rather than the empty concrete key list, mirroring how the other export actions already resolve the full result set from the query. This ensures the PDF export can resolve every matching report on the server side instead of relying on the page-limited selection.

3. Keep the on-page selection behavior unchanged so that when only specific reports are selected, the existing concrete-keys path continues to drive the PDF export.

This fixes the root cause because the PDF option is no longer conditional on a page-limited key list, so it stays available and correctly targets all matching reports in the select-all-across state.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Reports page, after bulk-selecting and choosing "Select all" (all matching reports across pages, not just the current page), the Selected dropdown no longer offers "Download as PDF". The option is available when using "Select all on this page", so users expect it to also be available for the full matching set.

What is the root cause of that problem?

The bulk actions dropdown is built in headerButtonsOptions in useSearchBulkActions (src/hooks/useSearchBulkActions.ts). When the user picks "Select all" from SearchSelectAllMenu, selectAllMatchingItems(true) sets areAllMatchingItemsSelected in SearchSelectionProvider, and the options memo short-circuits to a single item, the CSV/template Export submenu:

App/src/hooks/useSearchBulkActions.ts

Lines 1662 to 1664 in c81c4b7

	if (areAllMatchingItemsSelected) {
	return [exportButtonOption];
	}

The "Download as PDF" option is only pushed much later in the same memo, so with select-all-matching active this code is unreachable:

App/src/hooks/useSearchBulkActions.ts

Lines 1915 to 1919 in c81c4b7

	if (isExpenseReportSearch && selectedReportIDs.length > 0) {
	options.push({
	icon: expensifyIcons.Download,
	text: translate('common.downloadAsPDF'),
	value: CONST.SEARCH.BULK_ACTION_TYPES.DOWNLOAD_PDF,

Git history shows this is an omission, not a product decision about PDF. The if (areAllMatchingItemsSelected) return [exportButtonOption] early return dates back to the original "export all matching" work in June 2025 (commit 403afebafec), when export was the only action that could operate on a query rather than explicit IDs. The PDF option was added a year later (PR #90143, commit 8c7e93f1a70, single report only) and extended to multi-select in PR #92275 (commit 5729983c94d), and neither PR revisited the early return, so PDF export silently inherited the "hidden under select-all" behavior.

There is a real constraint hiding behind the early return, and the fix has to respect it. With select-all-matching, the client only holds the fetched pages: SearchWriteActionsProvider propagates isSelected to loaded rows, so selectedReportIDs contains only loaded reports, while the selection semantically covers every report matching the query (the select-all menu only even appears when hasMoreResults is true). The query-based exports handle this by sending the serialized query to the backend (queueExportSearchWithTemplate sends jsonQuery: serializedQuery, reportIDList: [] at line 631, and queueExportSearchItemsToCSV similarly at line 732). The PDF action cannot do that today because ExportReportsToPDF is ID-only, write(WRITE_COMMANDS.EXPORT_REPORTS_TO_PDF, {reportIDs: JSON.stringify(reportIDs), exportID}, ...) in src/libs/actions/Export.ts (line 101), with ExportReportsToPDFParams containing just reportIDs and exportID. So simply moving the option above the early return would silently export only the loaded page(s), which is why the fix needs the query-based variant described below.

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

The fix follows the exact pattern the CSV/template exports already use for select-all: offer the option, and when areAllMatchingItemsSelected is true send the serialized query instead of explicit IDs so the backend resolves the full matching set server-side. The multi-report PDF flow already runs asynchronously through the EXPORT_DOWNLOAD Onyx collection with the ExportDownloadStatusModal and Concierge handoff for large exports (shouldSendFromConcierge), so it is count-agnostic and safe for arbitrarily large selections; only the parameterization is ID-bound.

In src/hooks/useSearchBulkActions.ts, hoist the isExpenseReportSearch computation (currently at line 1701) above the early return, build the PDF option there, and include it in the select-all return. Before:

if (areAllMatchingItemsSelected) {
    return [exportButtonOption];
}

After:

const isExpenseReportSearch = isExpenseReportType || searchResults?.search.type === CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT;
const downloadPDFOption: DropdownOption<SearchHeaderOptionValue> = {
    icon: expensifyIcons.Download,
    text: translate('common.downloadAsPDF'),
    value: CONST.SEARCH.BULK_ACTION_TYPES.DOWNLOAD_PDF,
    shouldCloseModalOnSelect: true,
    onSelected: async () => {
        if (isOffline) {
            setIsOfflineModalVisible(true);
            return;
        }
        if (areAllMatchingItemsSelected) {
            const exportID = exportReportsToPDF([], queryJSON ? serializeQueryJSONForBackend(queryJSON) : undefined);
            trackExport(exportID);
            return;
        }
        if (selectedReportIDs.length === 1) {
            const reportIDForPDF = selectedReportIDs.at(0);
            if (!reportIDForPDF) {
                return;
            }
            await exportReportToPDF({reportID: reportIDForPDF});
            setPdfReportID(reportIDForPDF);
            setIsPdfModalVisible(true);
            return;
        }
        const exportID = exportReportsToPDF(selectedReportIDs);
        trackExport(exportID);
    },
};

if (areAllMatchingItemsSelected) {
    return isExpenseReportSearch ? [exportButtonOption, downloadPDFOption] : [exportButtonOption];
}

The later block at lines 1915-1940 then shrinks to if (isExpenseReportSearch && selectedReportIDs.length > 0) { options.push(downloadPDFOption); } (and the now-duplicate isExpenseReportSearch declaration at line 1701 is removed), so the non-select-all behavior, including the single-report ReportPDFDownloadModal path, is byte-for-byte unchanged. In src/libs/actions/Export.ts, exportReportsToPDF gains an optional query parameter, mirroring QueueExportSearchItemsToCSV:

App/src/libs/actions/Export.ts

Lines 101 to 103 in c81c4b7

	write(WRITE_COMMANDS.EXPORT_REPORTS_TO_PDF, {reportIDs: JSON.stringify(reportIDs), exportID}, {optimisticData, failureData});
	return exportID;

function exportReportsToPDF(reportIDs: string[], jsonQuery?: string): string {
    ...
    write(WRITE_COMMANDS.EXPORT_REPORTS_TO_PDF, {reportIDs: JSON.stringify(reportIDs), jsonQuery, exportID}, {optimisticData, failureData});

with ExportReportsToPDFParams in src/libs/API/parameters/ExportReportsToPDFParams.ts becoming {reportIDs: string; exportID: string; jsonQuery?: string}. The Auth side of ExportReportsToPDF needs a small internal counterpart: when jsonQuery is present, resolve the matching report IDs from the query (the same resolution QueueExportSearchItemsToCSV and ExportSearchWithTemplate already perform) instead of reading reportIDs. Because delivery already goes through the async export pipeline with the Concierge fallback for large files, no new size cap is needed on the client; if the backend wants to enforce a report-count limit for a single PDF it can fail the export, which the existing failureData path (EXPORT_DOWNLOAD state FAILED) already surfaces in the status modal. The gate on isExpenseReportSearch keeps the option off Expenses/Chats/Invoices searches under select-all, matching its behavior for page selection, and the existing selectedTransactionsKeys.length === 0 || !hash guard at the top of the memo is unaffected because select-all also marks all loaded rows selected.

What specific alternative solutions did you consider? (Optional)

A client-only fix that shows the option under select-all and sends the currently loaded selectedReportIDs to the existing ID-based API. Rejected because the select-all menu only appears when hasMoreResults is true, so this would always silently produce a PDF export missing the unfetched reports, which is worse than hiding the option. Also considered fetching all matching pages client-side before calling exportReportsToPDF, but that duplicates work the backend already does for the query-based CSV/template exports and would be slow and fragile for large result sets, which is exactly the case select-all exists for.

What specific regression tests should cover this? (Optional)

As a workspace admin with more expense reports than one search page, go to Reports, enter selection mode, open the select-all checkbox menu and choose "Select all", then open the Selected dropdown and verify "Download as PDF" is shown; select it and verify the export status modal appears and the delivered PDF contains all matching reports, not just the loaded page. Repeat with "Select all on this page" for one report and for multiple reports to confirm the single-report download modal and the multi-report async export still work, and run an Expenses (non report) search with select-all to confirm "Download as PDF" is still not offered there.

[ahmdshrif]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[aswin-s]

Note: This proposal is not a duplicate. It changes a different location in the code to address the issue.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Web (Spend > Reports), when a workspace admin uses "Select all" to select all matching reports across pages and opens the Selected dropdown, the "Download PDF" option is missing from the export menu. It is only shown when using "Select all on this page". Expected: "Download PDF" should also be available when "Select all" (all matching items) is used.

What is the root cause of that problem?

In src/hooks/useSearchBulkActions.ts inside the headerButtonsOptions memo (defined at line 1458), the branch at lines 1662–1664 short-circuits and returns only [exportButtonOption] whenever areAllMatchingItemsSelected is true. This early return happens before the DOWNLOAD_PDF option (pushed at lines 1915–1940, gated on isExpenseReportSearch && selectedReportIDs.length > 0) is ever added to the options array. As a result, the consumer SearchBulkActionsButton (src/components/Search/SearchBulkActionsButton.tsx:66,175,223) receives options with no Download PDF entry in the "Select all matching" case, even though the same underlying flow (bulk export of report IDs, which already supports the "all matching" case via exportReportsToPDF at line 1936) is capable of running.

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

1. In src/hooks/useSearchBulkActions.ts at lines 1662–1664, do not unconditionally short-circuit to [exportButtonOption] when areAllMatchingItemsSelected is true. Instead, when the query is an expense-report search and at least one report is (or all matching reports are) selected, also include the DOWNLOAD_PDF option (same definition as lines 1916–1939) alongside exportButtonOption.
2. Extract the DOWNLOAD_PDF option object (lines 1916–1939) into a local const downloadPdfOption earlier in the memo so it can be reused in both the "all matching" branch and the normal branch, avoiding duplication.
3. Ensure the onSelected handler in the "all matching" case uses exportReportsToPDF(selectedReportIDs) + trackExport(exportID) (the multi-report path at line 1936) since single-report modal (ReportPDFDownloadModal) is not meaningful for the all-matching set.
4. Verify selectedReportIDs is populated when areAllMatchingItemsSelected is true for expense-report searches; if it is not, extend the "all matching" branch to derive the report ID list from currentSearchResults before enabling the option, so the entry is only shown when a valid export target exists.
5. No sibling native/iOS/Android files to patch — this hook and SearchBulkActionsButton are Web-only surfaces for the Spend > Reports Selected dropdown.

What alternative solutions did you explore? (Optional)

[lorretheboy]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-15 21:33:19 UTC.

Note: This isn't a duplicate — Different root cause: the flagged proposal blames the isExpenseReportSearch && selectedReportIDs.length > 0 gate being empty in select-all mode, but SearchWriteActionsProvider (src/components/Search/SearchWriteActionsProvider.tsx:153-208) marks every loaded row selected when areAllMatchingItemsSelected, so that list is non-empty and its gate never fires — the real blocker is the unconditional return [exportButtonOption] at src/hooks/useSearchBulkActions.ts:1662-1664, which returns before line 1915 is ever reached. Materially different fix: their step 1 ("stop gating Download PDF on a non-empty concrete selectedReports list") would not change the menu at all since the early return precedes that gate; ours removes the early-return short-circuit and hoists isExpenseReportSearch/the PDF option above it, plus adds jsonQuery to ExportReportsToPDFParams (which today only accepts reportIDs/exportID).

Proposal

What is the root cause of that problem?

When "Select all" (all matching) is on, headerButtonsOptions returns early with only the export button:

App/src/hooks/useSearchBulkActions.ts

Lines 1662 to 1664 in c81c4b7

	if (areAllMatchingItemsSelected) {
	return [exportButtonOption];
	}

The Download PDF option is pushed further down, after that return, so it is never reached:

App/src/hooks/useSearchBulkActions.ts

Lines 1915 to 1940 in c81c4b7

	if (isExpenseReportSearch && selectedReportIDs.length > 0) {
	options.push({
	icon: expensifyIcons.Download,
	text: translate('common.downloadAsPDF'),
	value: CONST.SEARCH.BULK_ACTION_TYPES.DOWNLOAD_PDF,
	shouldCloseModalOnSelect: true,
	onSelected: async () => {
	if (isOffline) {
	setIsOfflineModalVisible(true);
	return;
	}
	if (selectedReportIDs.length === 1) {
	const reportIDForPDF = selectedReportIDs.at(0);
	if (!reportIDForPDF) {
	return;
	}
	await exportReportToPDF({reportID: reportIDForPDF});
	setPdfReportID(reportIDForPDF);
	setIsPdfModalVisible(true);
	return;
	}
	const exportID = exportReportsToPDF(selectedReportIDs);
	trackExport(exportID);
	},
	});
	}

Why only export survives the early return: "Select all" merely flips a flag — it doesn't (and can't) enumerate the matching reports, since results are paged and the count comes from the server:

App/src/components/Search/SearchList/SearchSelectAllMenu.tsx

Lines 48 to 51 in c81c4b7

	const selectAllMatching = useCallback(() => {
	closeSelectAllMenu();
	selectAllMatchingItems(true);
	}, [closeSelectAllMenu, selectAllMatchingItems]);

The export submenu still works in that mode because it sends the search query to the backend instead of an ID list:

App/src/hooks/useSearchBulkActions.ts

Lines 630 to 642 in c81c4b7

	if (areAllMatchingItemsSelected) {
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: serializedQuery,
	reportIDList: [],
	transactionIDList: [],
	policyID,
	exportName,
	},
	true,
	);

but exportReportsToPDF can only be given report IDs:

App/src/libs/actions/Export.ts

Lines 81 to 101 in c81c4b7

	function exportReportsToPDF(reportIDs: string[]): string {
	const exportID = rand64();
	const onyxKey = `${ONYXKEYS.COLLECTION.EXPORT_DOWNLOAD}${exportID}` as const;
	const optimisticData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {state: CONST.EXPORT_DOWNLOAD.STATE.PREPARING, exportType: CONST.EXPORT_DOWNLOAD.TYPE.PDF},
	},
	];
	const failureData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {state: CONST.EXPORT_DOWNLOAD.STATE.FAILED, exportType: CONST.EXPORT_DOWNLOAD.TYPE.PDF},
	},
	];
	write(WRITE_COMMANDS.EXPORT_REPORTS_TO_PDF, {reportIDs: JSON.stringify(reportIDs), exportID}, {optimisticData, failureData});

So PDF was dropped wholesale for select-all rather than made query-aware, which is the actual bug.

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

Build the Download PDF option once (moving isExpenseReportSearch above the early return, since it's currently computed after it), and include it in the select-all return instead of returning export alone:

App/src/hooks/useSearchBulkActions.ts

Lines 1662 to 1664 in c81c4b7

	if (areAllMatchingItemsSelected) {
	return [exportButtonOption];
	}

if (areAllMatchingItemsSelected) {
    return isExpenseReportSearch ? [exportButtonOption, downloadPDFOption] : [exportButtonOption];
}

And give the PDF export the same query-based shape the template export already uses, so it covers reports that haven't been paged in yet: add jsonQuery to ExportReportsToPDFParams and pass serializeQueryJSONForBackend(queryJSON) with an empty reportIDs when areAllMatchingItemsSelected, letting the server resolve the matching reports — exactly as here:

App/src/hooks/useSearchBulkActions.ts

Lines 630 to 642 in c81c4b7

	if (areAllMatchingItemsSelected) {
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: serializedQuery,
	reportIDList: [],
	transactionIDList: [],
	policyID,
	exportName,
	},
	true,
	);

The existing ID-based call (and the single-report exportReportToPDF shortcut) stays for normal selections. This needs the backend ExportReportsToPDF command to accept jsonQuery, same as ExportSearchItemsToCSV does.

What alternative solutions did you explore? (Optional)

Frontend-only, no API change: show the option in select-all mode and pass the already-selected selectedReportIDs. It ships immediately, but it would silently produce a PDF of only the reports currently loaded on the page, which is misleading when the search has more results.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[abbasifaizan70]

Note > This proposal is not a duplicate because the reference proposal was posted before the help-wanted tag.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the workspace Spend > Reports page, when an admin uses Select all to select every matching report across all pages (not just the current page), the Selected > Export menu no longer offers Download PDF, even though the same set of reports (when selected via "Select all on this page") does show that option.

What is the root cause of that problem?

The bulk-actions menu is built in useSearchBulkActions.ts. When the "select all matching" flag is on, the function short-circuits and returns only the Export (CSV/template) button, before it ever reaches the code that conditionally adds the Download PDF entry:

App/src/hooks/useSearchBulkActions.ts

Lines 1664 to 1666 in 9813012

	if (areAllMatchingItemsSelected) {
	return [exportButtonOption];
	}

The Download PDF option is only pushed further down, and it's gated on there being at least one concrete report id in selectedReportIDs:

App/src/hooks/useSearchBulkActions.ts

Lines 1917 to 1942 in 9813012

	if (isExpenseReportSearch && selectedReportIDs.length > 0) {
	options.push({
	icon: expensifyIcons.Download,
	text: translate('common.downloadAsPDF'),
	value: CONST.SEARCH.BULK_ACTION_TYPES.DOWNLOAD_PDF,
	shouldCloseModalOnSelect: true,
	onSelected: async () => {
	if (isOffline) {
	setIsOfflineModalVisible(true);
	return;
	}
	if (selectedReportIDs.length === 1) {
	const reportIDForPDF = selectedReportIDs.at(0);
	if (!reportIDForPDF) {
	return;
	}
	await exportReportToPDF({reportID: reportIDForPDF});
	setPdfReportID(reportIDForPDF);
	setIsPdfModalVisible(true);
	return;
	}
	const exportID = exportReportsToPDF(selectedReportIDs);
	trackExport(exportID);
	},
	});
	}

selectedReportIDs is derived purely from the individually-tracked selectedReports state:

App/src/hooks/useSearchBulkActions.ts

Lines 467 to 469 in 9813012

	const selectedReportIDs = Object.values(selectedReports)
	.map((report) => report.reportID)
	.filter((reportID) => reportID !== undefined);

but toggling "select all matching" never populates selectedReports with every matching report (that's not even loaded client-side across all pages) — it just flips a boolean:

App/src/components/Search/SearchSelectionProvider.tsx

Lines 127 to 137 in 9813012

	const selectAllMatchingItems: SearchSelectionActionsValue['selectAllMatchingItems'] = (shouldSelectAll) => {
	setSelectionState((prevState) => {
	if (prevState.areAllMatchingItemsSelected === shouldSelectAll) {
	return prevState;
	}
	return {
	...prevState,
	areAllMatchingItemsSelected: shouldSelectAll,
	};
	});
	};

So even without the early return, selectedReportIDs would be empty (or only reflect the current page) in "select all matching" mode, and Download PDF would never render.

This is unlike CSV and template exports, which already have a dedicated code path for "select all matching": they send an empty id list plus the serialized search jsonQuery so the backend can resolve which reports/transactions to export (see the areAllMatchingItemsSelected branches used for template export and CSV export). exportReportsToPDF, however, only accepts an explicit list of report ids and has no query-based variant:

App/src/libs/actions/Export.ts

Lines 81 to 104 in 9813012

	function exportReportsToPDF(reportIDs: string[]): string {
	const exportID = rand64();
	const onyxKey = `${ONYXKEYS.COLLECTION.EXPORT_DOWNLOAD}${exportID}` as const;
	const optimisticData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {state: CONST.EXPORT_DOWNLOAD.STATE.PREPARING, exportType: CONST.EXPORT_DOWNLOAD.TYPE.PDF},
	},
	];
	const failureData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {state: CONST.EXPORT_DOWNLOAD.STATE.FAILED, exportType: CONST.EXPORT_DOWNLOAD.TYPE.PDF},
	},
	];
	write(WRITE_COMMANDS.EXPORT_REPORTS_TO_PDF, {reportIDs: JSON.stringify(reportIDs), exportID}, {optimisticData, failureData});
	return exportID;
	}

So PDF export was simply never wired up to support the "select all matching" flow that the other bulk export types already support.

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

Add a query-based path for PDF export, mirroring the existing jsonQuery pattern used by CSV/template export, and surface Download PDF in the "select all matching" branch of the menu.

https://github.com/Expensify/App/blob/98130124dd6e9330a0f955cb41beaf08470248e5/src/libs/actions/Export.ts#L81-L104

function exportReportsToPDF(reportIDs: string[], jsonQuery?: string): string {
    ...
    write(
        WRITE_COMMANDS.EXPORT_REPORTS_TO_PDF,
        {reportIDs: JSON.stringify(reportIDs), jsonQuery, exportID},
        {optimisticData, failureData},
    );
    return exportID;
}

https://github.com/Expensify/App/blob/98130124dd6e9330a0f955cb41beaf08470248e5/src/hooks/useSearchBulkActions.ts#L1664-L1666

if (areAllMatchingItemsSelected) {
    const allMatchingOptions = [exportButtonOption];
    const isExpenseReportSearch =
        isExpenseReportType || searchResults?.search.type === CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT;

    if (isExpenseReportSearch) {
        allMatchingOptions.push({
            icon: expensifyIcons.Download,
            text: translate('common.downloadAsPDF'),
            value: CONST.SEARCH.BULK_ACTION_TYPES.DOWNLOAD_PDF,
            shouldCloseModalOnSelect: true,
            onSelected: () => {
                if (isOffline) {
                    setIsOfflineModalVisible(true);
                    return;
                }

                const serializedQuery = queryJSON
                    ? serializeQueryJSONForBackend(queryJSON)
                    : JSON.stringify(queryJSON);

                const exportID = exportReportsToPDF([], serializedQuery);
                trackExport(exportID);
            },
        });
    }

    return allMatchingOptions;
}

This keeps the existing per-report Download PDF behavior unchanged for the "select all on this page" case (explicit selectedReportIDs, no jsonQuery), while letting "select all matching" reports resolve the report set server-side from the search query, the same way CSV/template exports already do.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

getOptions in useSearchBulkActions returns early with a hard-coded one-item list the moment Select all (all matching) is active:

App/src/hooks/useSearchBulkActions.ts

Lines 1662 to 1664 in c81c4b7

	if (areAllMatchingItemsSelected) {
	return [exportButtonOption];
	}

Everything after that line is dead code in this mode — including the Download PDF option, which is only pushed ~250 lines later:

App/src/hooks/useSearchBulkActions.ts

Lines 1913 to 1920 in c81c4b7

	options.push(exportButtonOption);
	if (isExpenseReportSearch && selectedReportIDs.length > 0) {
	options.push({
	icon: expensifyIcons.Download,
	text: translate('common.downloadAsPDF'),
	value: CONST.SEARCH.BULK_ACTION_TYPES.DOWNLOAD_PDF,
	shouldCloseModalOnSelect: true,

That's the entire asymmetry in the report. With Select all on this page, areAllMatchingItemsSelected is false, execution reaches L1915, isExpenseReportSearch && selectedReportIDs.length > 0 holds, and the option renders. With Select all, the early return fires first and the menu is capped at Export.

The important part — and the reason I don't think the one-line fix is the right one — is why that early return exists.

In all-matching mode the client does not know what it selected. selectAllMatchingItems only flips a boolean; it never materializes the unselected rows:

App/src/components/Search/SearchSelectionProvider.tsx

Lines 127 to 135 in c81c4b7

	const selectAllMatchingItems: SearchSelectionActionsValue['selectAllMatchingItems'] = (shouldSelectAll) => {
	setSelectionState((prevState) => {
	if (prevState.areAllMatchingItemsSelected === shouldSelectAll) {
	return prevState;
	}
	return {
	...prevState,
	areAllMatchingItemsSelected: shouldSelectAll,
	};

Search results are paginated behind hasMoreResults, so rows past the loaded offset simply aren't in Onyx:

App/src/components/Search/index.tsx

Lines 729 to 733 in c81c4b7

	if (!isFocused || !searchResults?.search?.hasMoreResults || shouldShowLoadingState || shouldShowLoadingMoreItems || offset > allDataLength - CONST.SEARCH.RESULTS_PAGE_SIZE) {
	return;
	}
	setOffset((prev) => prev + CONST.SEARCH.RESULTS_PAGE_SIZE);

And selectedReportIDs is derived purely from what's in the selection context:

App/src/hooks/useSearchBulkActions.ts

Lines 467 to 469 in c81c4b7

	const selectedReportIDs = Object.values(selectedReports)
	.map((report) => report.reportID)
	.filter((reportID) => reportID !== undefined);

So in all-matching mode selectedReportIDs covers the loaded rows, not every matching report. Export survives the early return because its all-matching path doesn't send IDs — it sends the serialized query with an empty reportIDList and lets the backend resolve the set:

App/src/hooks/useSearchBulkActions.ts

Lines 630 to 641 in c81c4b7

	if (areAllMatchingItemsSelected) {
	exportID = queueExportSearchWithTemplate(
	{
	templateName,
	templateType,
	jsonQuery: serializedQuery,
	reportIDList: [],
	transactionIDList: [],
	policyID,
	exportName,
	},
	true,

Download PDF has no equivalent path, and this is the real blocker rather than the menu gating. exportReportsToPDF serializes an ID array and nothing else:

App/src/libs/actions/Export.ts

Lines 81 to 104 in c81c4b7

	function exportReportsToPDF(reportIDs: string[]): string {
	const exportID = rand64();
	const onyxKey = `${ONYXKEYS.COLLECTION.EXPORT_DOWNLOAD}${exportID}` as const;
	const optimisticData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {state: CONST.EXPORT_DOWNLOAD.STATE.PREPARING, exportType: CONST.EXPORT_DOWNLOAD.TYPE.PDF},
	},
	];
	const failureData: AnyOnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: onyxKey,
	value: {state: CONST.EXPORT_DOWNLOAD.STATE.FAILED, exportType: CONST.EXPORT_DOWNLOAD.TYPE.PDF},
	},
	];
	write(WRITE_COMMANDS.EXPORT_REPORTS_TO_PDF, {reportIDs: JSON.stringify(reportIDs), exportID}, {optimisticData, failureData});
	return exportID;
	}

…because the command contract is IDs-only:

App/src/libs/API/parameters/ExportReportsToPDFParams.ts

Lines 1 to 4 in c81c4b7

	type ExportReportsToPDFParams = {
	reportIDs: string;
	exportID: string;
	};

I checked whether this could be routed through the existing query-aware export instead, and it can't: EXPORT_TEMPLATE_TYPES only has integrations and in-app, and queueExportSearchWithTemplate hard-codes exportType: CONST.EXPORT_DOWNLOAD.TYPE.CSV. There is no client-side way today to ask for "every report matching this query, as a PDF".

So: the option is hidden by L1662, but it is hideable because the PDF command can't express the all-matching case.

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

This needs a backend parameter, not just a frontend unhide. I'd sequence it that way.

1. Teach ExportReportsToPDF about the query. Add an optional jsonQuery to ExportReportsToPDFParams and thread it through exportReportsToPDF as an optional second argument. When it's present the backend resolves every matching report from the query and ignores reportIDs, exactly like the CSV side already does.

This isn't a new concept — it's the shape the other queued exports already use:

App/src/libs/API/parameters/ExportSearchItemsToCSVParams.ts

Lines 3 to 10 in c81c4b7

	type ExportSearchItemsToCSVParams = {
	jsonQuery: SearchQueryString;
	reportIDList: string[];
	transactionIDList: string[];
	isBasicExport: boolean;
	exportColumnLabels: string;
	exportName: string;
	};

2. Then unhide the option. Lift the Download PDF option at L1915-L1940 into a variable next to exportButtonOption, and return [exportButtonOption, downloadPDFOption] from the all-matching branch at L1662-L1664, keeping the existing isExpenseReportSearch gate. One definition, both branches, so they can't drift apart later.

Inside onSelected, branch on areAllMatchingItemsSelected: pass the serialized query (mirroring L630-L641) instead of selectedReportIDs. The selectedReportIDs.length === 1 shortcut that calls exportReportToPDF and opens the single-report modal must be skipped in this mode — the real count is unknown to the client, so it should always take the queued multi-report path.

The layer is the export command contract plus the option-list hook, because that's where the page-vs-all-matching distinction actually lives. Nothing about Select all on this page changes — it keeps the ID path it has today.

I want to be direct about why I'd hold part 2 until part 1 lands. Shipping the frontend alone makes the button appear and hands exportReportsToPDF only the loaded rows, so an admin clicks "Select all" over 500 reports and silently receives a PDF of the ~50 that happened to be loaded. A silently-partial export is a worse bug than a missing menu item, and it's one nobody would catch in QA on a small test account.

One thing I can't verify from this repo: whether the ExportReportsToPDF backend already tolerates a jsonQuery and only the client type is behind. If it does, this collapses to a frontend-only change. That's worth a quick check with whoever owns the command before anyone starts.

What alternative solutions did you explore? (Optional)

Route all-matching PDF through queueExportSearchWithTemplate, which already accepts jsonQuery — rejected. It hard-codes exportType: CSV in its Onyx state and EXPORT_TEMPLATE_TYPES has no PDF member, so there's nothing on that path that produces a PDF.

Load every matching page client-side before exporting, then pass the full ID list — rejected. It would fire an unbounded number of paginated search requests just to build an argument the backend can derive from the query itself, and it would still race any report that changes mid-fetch.

Drop the early return entirely and let all options fall through — rejected. It exists to stop ID-driven bulk actions (Pay, Hold, Approve) from silently acting on only the loaded page, so removing it trades one missing menu item for several silently-partial bulk operations.

[melvin-bot]

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