Agents - Import failed when columns are mapped correctly

[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.32-1
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: #95421
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Account > Agents.
3. Click New agent and add an agent.
4. Click Copilot on agent row.
5. Go to Account > Wallet.
6. Click Import transactions.
7. Click Card display name.
8. Enter display name > Save > Next.
9. Upload a valid file (attached below).
10. Map Date column.
11. Click Import.

Expected Result:

Transactions will be imported because columns are mapped correctly.

Actual Result:

Import failed when columns are mapped correctly.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7204051_1783620164022.9.1.mp4

Bug7204051_1783620164031!fake_transactions-2026-01-16.10_56_55.629.csv

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @NicolasBonet

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

https://platform.applause.com/services/links/v1/external/7808543c624f46544926b45a94aacbd6dbee253c049d6050bc2fcb1792dc729b

[melvin-bot]

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

[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 (medium confidence): The "Import failed" modal shown here is not a column‑mapping problem — it fires after client validation passes, when the backend IMPORT_CSV_TRANSACTIONS write command rejects/throws (or the file yields zero valid rows). The App‑side import flow has no agent‑specific logic at all, so the blamed PR (#95421) did not change import behavior — it only restored Wallet visibility for agent accounts, which newly exposed the "Import transactions" flow to agents. The failure is almost certainly the backend refusing to create an imported card for an agent_*@expensify.ai account (agents aren't wallet/card holders server‑side).

Why the title is misleading: With only the Date column mapped, you'd get an inline "Oops! A required field hasn't been mapped" error, never the "Import failed" modal (TransactionsImportedPage.tsx:75-91). The reported "Import failed" string only comes from the post‑validation path (ImportTransactions.ts:369-379), so the tester most likely did map all three required columns (date, merchant, amount) and the import failed downstream.

Recommended resolution (deploy blocker): This needs an Expensify decision, not an App code fix for validation:

1. If agents should NOT import their own CSV cards (most likely — PR Restore Wallet and other Account sections for agent accounts #95421's stated goal was only to let agents see assigned cards & transactions): re‑hide just the "Import transactions" entry point for agent accounts while keeping the rest of the Wallet visible. This is a small, App‑side change and unblocks the deploy without a full revert.
2. If agents SHOULD be able to import: the fix is server‑side (Web‑Expensify/Auth IMPORT_CSV_TRANSACTIONS command must accept agent cardholders). That is outside the App repo — an internal engineer should investigate and confirm the backend rejection.

Investigation details & evidence

"Import failed" is a post‑validation modal, not the mapping error:

• Required columns are date and merchant and amount, all isRequired: true — TransactionsImportedPage.tsx:75-91. Missing a required column short‑circuits before any API call and shows the inline fieldNotMapped text: "Oops! A required field (…) hasn't been mapped" (en.ts:1193).
• The "Import failed" title comes from getImportFailedFinalModal() (ImportSpreadsheet.ts:83-86, string at en.ts:1235-1236), reached only via two post‑validation paths:
  • zero valid rows built from the file → ImportTransactions.ts:262-267
  • API.write(IMPORT_CSV_TRANSACTIONS) throws / returns failure → catch at ImportTransactions.ts:369-379.

No agent handling in the import flow: grep for agent_ / expensify.ai / isAgent / copilot / delegate across ImportTransactions.ts, ImportSpreadsheet.ts, TransactionsImportedPage.tsx returns nothing. The import creates an optimistic card for the current importing user's accountID as cardholder (ImportTransactions.ts:246-247, 277-279) — i.e. it tries to make the agent a cardholder, which the backend likely rejects.

PR #95421 scope: touched only navigation/settings visibility (ModalStackNavigators, SettingsSplitNavigator, withAgentAccessDenied, InitialSettingsPage, ProfilePage, SecuritySettingsPage, TestToolMenu) — no import logic. It made the Wallet + "Import transactions" reachable for agents for the first time.

Alternative explanations considered: (a) plain client validation failure — ruled out, because that shows a different inline message, not the reported modal; (b) unparseable dates / non‑numeric amounts producing zero rows — possible but would reproduce for non‑agents too, whereas this is filed specifically against the agent flow that PR #95421 exposed.

Not yet confirmed with logs: I could not run VictoriaLogs this run (VL MCP not connected), so I have not confirmed the exact backend jsonCode. To verify, check whether IMPORT_CSV_TRANSACTIONS was invoked for the agent account and what it returned around the repro time — search tester activity 2026‑07‑09. A non‑200 there confirms the backend‑rejection root cause.

---

Next Steps for Contributor+ team:
To accept option 1 (hide Import for agents, App‑side): @MelvinBot implement [this](https://github.com/Expensify/App/issues/95755) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting this analysis.

[yuwenmemon]

Not a blocker.