Tags - Unable to import multilevel tags

[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.99-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-38469/folder/13176676/41237315/1461643979?sort=%2Bidentifier
Email or phone of affected tester (no customers): htad26+etjeriI@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 13/iOS 26.5
App Component: Workspace Settings

Action Performed:

1. Navigate to a workspace
2. Enable tags
3. Go to tags > Import > Multilevel tags (Upgrade if necessary)
4. Choose a multilevel tag file > Import

Expected Result:

The multilevel tags are imported without an issue

Actual Result:

Long loading and then eventually importing the tags fail

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7171379_1780565559928.video_2026-06-04_12-31-31.mp4

Bug7171379_1780566544533!Independent_with_GL_codes_format.csv

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7171379

Issue Owner

Current Issue Owner: @mkhutornyi

[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/5282fe5157273cec8bdcda2a938f3443dd23bce84f6f293baa3f8bd5433f6c73

https://platform.applause.com/services/links/v1/external/027522fc9638959385443939e7e6ea6ef1880f96fd2048ff79f00dca4b090742

[melvin-bot]

Triggered auto assignment to @cristipaval (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]

Issue Analysis

Root Cause: This is a deploy-blocker regression introduced by #92365 ("feat: Enable react-native-nitro-fetch", merged 2026-06-03). That PR activates the NitroFetch polyfill globally via index.js:5, which replaces the global fetch on native with react-native-nitro-fetch — a native HTTP client (URLSession on iOS) that cannot read local files.

The polyfill only falls back to the original fetch when the URL scheme matches file|blob|data|content (NitroFetch.ts:10,22-27). But on iOS the spreadsheet importer strips the file:// scheme, rewriting the picked file to a bare absolute path (ImportSpreadsheet.tsx:99-101). That scheme-less path no longer matches the fallback, so when the import reads the file via fetch(path) in readFileAsync (FileUtils.ts:249) it routes to NitroFetch, which can't read the local file → long URLSession timeout → "import failed".

This precisely matches the report:

• Staging only: 9.3.99-0 contains feat: Enable react-native-nitro-fetch #92365; production 9.3.98-3 does not (confirmed via the 9.3.98-3...9.3.99-0-staging compare).
• iOS only: Android's document-picker URI keeps a content:///file:// scheme that still matches the fallback, so it works there.

Recommended Fix:

1. Fastest unblock: revert feat: Enable react-native-nitro-fetch #92365 to restore the native fetch for the deploy.
2. Forward fix: invert the NitroFetch guard so only http(s) requests go through NitroFetch. The file's own comment states the intent ("route only http(s) requests through nitro-fetch"), but the implementation does the opposite (routes everything except a few schemes). Change NitroFetch.ts:22-27 to fall back to originalFetch whenever the URL is not http(s) (e.g. if (!/^https?:/i.test(getRequestUrl(input))) { return originalFetch(input, init); }). This restores all local-file reads (receipts, attachments, and every spreadsheet import), not just multilevel tags.

Note: because the scheme-stripping lives in the shared ImportSpreadsheet component, every iOS spreadsheet import (categories, single- and multi-level tags, members, per-diem) is broken on staging — the tester just happened to exercise multilevel tags.

Investigation details & evidence

Data flow (iOS):

1. User picks the CSV. readFile sets fileURI = file.uri, then on iOS rewrites it to a bare path via RNFetchBlob.fs.dirs.DocumentDir (no file://) — ImportSpreadsheet.tsx:99-101.
2. CSV parse uses fetch(fileURI) (ImportSpreadsheet.tsx:111/117); the same bare fileURI is persisted to Onyx.
3. User taps Import → importMultiLevelTags (Tag.ts:870-928) calls readFileAsync(spreadsheet.fileURI, …).
4. readFileAsync calls fetch(path) on the scheme-less path (FileUtils.ts:249) → NitroFetch (URLSession) can't read it → onFailure → getImportFailedFinalModal() after a long wait.

Polyfill history: src/polyfills/NitroFetch.ts existed since April but was only enabled (imported in index.js) by the nitro-fetch enablement work. The file|blob|data|content scheme fallback was added 2026-06-02 (8b62d50a / f2be260c) — it covers schemed URIs but misses iOS's rewritten bare path.

Why not a backend bug? The command never reaches the backend on iOS staging — the failure is client-side in fetch() before API.write(IMPORT_MULTI_LEVEL_TAGS) fires. The change is also App-only and timing-aligned with the staging-vs-production delta. (Log confirmation wasn't available in this environment, but the code path + release timing + iOS/staging-only signature are conclusive.)

Related (possibly): #91840 ("Choose from file page is not displayed when importing multilevel Tags") is a different symptom (page not shown) and predates this regression, but it's in the same import flow and worth a glance when fixing.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [the forward fix](https://github.com/Expensify/App/blob/373d821566821165098a21bb5eed66c333213820/src/polyfills/NitroFetch.ts#L22-L27) to create a draft PR — or simply revert #92365.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting this analysis.

[mkhutornyi]

I am not able to reproduce in local build.

ios.mov

[mkhutornyi]

@MelvinBot implement Option 2 - Forward fix