Export - Custom export template file is not delivered to Concierge

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.1-5
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92131
Email or phone of affected tester (no customers): applausetester+th08@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11
App Component: Other

Action Performed:

Preconditions

1. Have an account-level custom export template created in Classic Expensify.
2. The template contains either {expense:category} or {expense:tag}.
3. Have expenses available for export.

Steps

1. Open Classic Expensify.
2. Create a new account-level custom export template containing {expense:category} or {expense:tag}.
3. Save the template.
4. Open New Expensify.
5. Navigate to Spend > Expenses.
6. Select one or more expenses.
7. Click Export.
8. Select the newly created custom export template.
9. Complete the export flow.
10. Open the Concierge chat.

Expected Result:

The export file is generated and delivered to Concierge using the selected custom export template.

Actual Result:

The message "Export in progress. Concierge will send you the file shortly." is displayed, indicating that the export request was accepted. However, no export file is delivered to Concierge even after waiting several minutes. Existing/default export templates generate and deliver files successfully.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7176038_1781017239926.Grabando__866.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7176038

[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/dbb8f63ac649667132fca9175a17e925e207ff808d2988f0d1cad009102988cb

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92131

[melvin-bot]

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

[github-actions]

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

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

[MelvinBot]

Issue Analysis

Root Cause: PR #92131 (merged 2026-06-08, in this deploy) changed both export paths to send a workspace policyID to the backend QueueExportSearchWithTemplate command for account-level custom templates, which previously sent policyID: undefined by design. For account-level templates the backend appears to fail to generate/deliver a file when a policyID is now present — so the optimistic "Export in progress…" message shows, but no file ever reaches Concierge. This is exactly the code path the QA repro exercises (account-level template containing {expense:category}/{expense:tag}), and the deploy-blocker was auto-assigned to the PR author for this same PR.

The two changed lines:

• useSearchBulkActions.ts:560 — exportPolicyID now resolves to the selection's workspace ID instead of undefined (used at L569 / L579)
• useExportActions.ts:136 — policyID: policyID ?? moneyRequestReport.policyID

Recommended Fix (deploy-blocker): Revert PR #92131 to immediately unblock the deploy. Reverting restores the prior behavior where account-level templates deliver the file (the only downside is the original cosmetic blank-GL-code bug, #89388, returns — a far lesser issue than total export failure).

The proper forward fix lives in the backend QueueExportSearchWithTemplate command (outside the App repo — likely Web-Expensify/Auth): it must tolerate a policyID for account-level templates and still generate the file for plain {expense:category}/{expense:tag} columns. That requires an internal engineer with backend access — I can't read or fix that code from the App repo.

Investigation details & confidence

Evidence chain (frontend, confirmed):

• Before fix: pass workspace policyID when exporting with account-level custom templates #92131, both paths forwarded the template's own policyID, which is undefined for account-level templates (per getExportTemplates). The backend received no policyID and delivered the file.
• After fix: pass workspace policyID when exporting with account-level custom templates #92131, useSearchBulkActions computes exportPolicyID from the selection/query and useExportActions falls back to moneyRequestReport.policyID, so the backend now receives a real workspace ID.
• The frontend call itself is unchanged otherwise: queueExportSearchWithTemplate just forwards the params to API.write(QueueExportSearchWithTemplate). The new value being sent is the only behavioral difference.

What I could NOT confirm: the exact backend failure mechanism (why a present policyID causes the file not to generate for plain category/tag templates). I attempted to pull production/staging logs for QueueExportSearchWithTemplate but VictoriaLogs was unavailable in this run. Suggested queries for whoever picks this up:

• {type=web} "QueueExportSearchWithTemplate" (staging, 2026-06-07 → 2026-06-09)
• {type=web} email:="applausetester+th08@applause.expensifail.com" ("export" OR "csv") (level:=error OR "Exception")

Alternative explanations considered: A pure frontend silent-failure (e.g., exportPolicyID throwing) is unlikely — the optimistic "Export in progress…" message is shown, meaning the API.write fired successfully; the failure is in backend job processing. The repro also notes default/existing templates still work, which isolates the break to the account-level + policyID combination introduced by this PR.

Why "Reproducible in production?: No": production hasn't received this deploy yet; the change is only on staging. Consistent with #92131 being the cause.

Confidence: High that #92131 is the trigger (direct code evidence + matching repro). Medium on the precise backend mechanism (unconfirmed by logs).

---

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