Tag - Import tag file shows error.

[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: V9.3.91-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Workspace Settings

Action Performed:

1. Launch app
2. Go to workspace settings
3. Enable tags - settings - import tag csv

Expected Result:

Import tag file must be successful.

Actual Result:

Import tag file shows error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169340_1780384560012.Screenrecorder-2026-06-02-12-42-08-136.mp4

Bug7169340_1780384664569!Tags-2026-06-02_07_11_49.543.csv

View all open jobs on GitHub

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

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

https://platform.applause.com/services/links/v1/external/7490ebdc4fc75bf19e79b005fd3a4e96ccc90cddd11e45a3c36559b360a1c376

[melvin-bot]

Triggered auto assignment to @NicolasBonet (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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]

Proposal

Likely regression from Expensify/App#90620 ("Refactor ImportSpreadsheetConfirmModal flow"), merged to main on 2026-05-26. It's in the 9.3.91 staging build but not yet in production — which matches "reproducible in staging, not production".

What is the root cause of that problem?

Before that PR, importPolicyTags sent the ImportTagsSpreadsheet command via API.write — a queued, offline‑tolerant write that only showed the failure modal through the request's failureData. The PR switched it to API.makeRequestWithSideEffects and now shows the "Import failed" modal for any response whose jsonCode is not exactly 200, or if the request throws:

• src/libs/actions/Policy/Tag.ts:245 — return response?.jsonCode === CONST.JSON_CODE.SUCCESS ? importFinalModal : getImportFailedFinalModal();
• Call site: ImportedTagsPage.tsx:121-130

So the import surfaces an error whenever the ImportTagsSpreadsheet request returns a non‑200 jsonCode (or a transient/network error) — cases the old queued path treated as success. The command name and parameters are unchanged; only the client invocation changed.

The same refactor was applied identically to categories, members, per‑diem, company‑card, and wallet imports (API/types.ts:1481-1484), so those flows are likely affected too.

⚠️ I could not confirm from production logs whether the backend returns a non‑200 code, or returns 200 while the client mis‑handles the response (VictoriaLogs wasn't queryable from this environment). That distinction decides whether the real fix is frontend‑only or also backend. High confidence that #90620 is the regression source; medium confidence on the precise failure trigger.

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

As this is a deploy blocker and #90620 is the only relevant change between working production and broken staging, the safest action is to revert Expensify/App#90620 (or CP‑revert it onto the staging branch).

If a fix‑forward is preferred, the import actions should stop treating every non‑200 response as a hard failure and restore the offline‑tolerant behavior of the previous queued write, only showing the failure modal on a genuine backend error. This requires the log confirmation noted above to pin the exact non‑200 code being returned.

What alternative solutions did you explore? (Optional)

Confirm via logs whether ImportTagsSpreadsheet returns a non‑200 jsonCode on staging. If it does, the backend command (outside the App repo) needs a separate look and an internal engineer should investigate it; if it returns 200, the fix is entirely in the App client's response handling.

Investigation details

Why #90620 is the regression source

• The merge commit 3e3f6e14360 is an ancestor of the 9.3.91 staging HEAD (1d4a19f), confirming it shipped to staging.
• It directly rewrote the tag import path. Diff of importPolicyTags:
  • Old: API.write(WRITE_COMMANDS.IMPORT_TAGS_SPREADSHEET, parameters, onyxData) with success/failure modals driven by onyxData.
  • New: await API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.IMPORT_TAGS_SPREADSHEET, parameters) with a strict jsonCode === 200 success check, else getImportFailedFinalModal().
• ImportTagsSpreadsheet was moved from WRITE_COMMANDS to SIDE_EFFECT_REQUEST_COMMANDS (API/types.ts:1484).
• The failure modal helper: getImportFailedFinalModal in ImportSpreadsheet.ts:82.

Validation considered & ruled out: the frontend validate() in ImportedTagsPage guards the missing/duplicate/empty Name column before the request fires, so a mapping error is not the cause of a consistent post‑Import failure.

Suggested log queries to confirm the trigger (run where VictoriaLogs is available):

• {type=web} "ImportTagsSpreadsheet" | stats by (jsonCode) count() over 2026-05-26 → 2026-06-02
• {type=web} email:="dreamnitethedragon+vegst@gmail.com" "ImportTagsSpreadsheet" over 2026-06-01 → 2026-06-02

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR (a revert of #90620, or a fix‑forward per the above).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.