Android - Tags - Multi level tags file cannot be imported

[mitarachim]

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.3.36-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: #83359
Email or phone of affected tester (no customers): sjodijsnodijdnoijsido@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace settings > Tags.
3. Tap Import.
4. Tap Multi-level tags.
5. Upload file.
6. Tap Next.
7. Tap Import.

Expected Result:

Multi level tags file can be imported.

Actual Result:

Multi level tags file cannot be imported.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7100354_1773260886651.Screen_Recording_20260312_042709_Expensify.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #83359 - "Enable platform tree shaking in hermes bundle" by @rinej (High confidence)
Related Issues: #80844 (previous identical issue)

Recommendation: REVERT

PR #83359 re-introduced the same babel/metro config changes that caused identical tag import failures in January 2026. The PR enabled experimentalImportSupport and disableImportExportTransform which breaks dynamic imports of the xlsx library used for spreadsheet parsing in tag imports.

This is a known regression - the exact same changes were previously merged in PR #80110, caused the same tag import failure (issue #80844), and were reverted in PR #80984. PR #83359 attempts to reintroduce these changes but has not resolved the underlying issue.

Labels: Keeping DeployBlockerCash (App deploy is blocked). This is a frontend bug requiring revert of App PR #83359.

Detailed Analysis

Evidence

• Issue only reproducible on staging (v9.3.36-0), not production - aligns with PR Enable platform tree shaking in hermes bundle #83359 deployment
• Identical symptoms to issue #80844: multi-level tag import fails on Android App
• PR Enable platform tree shaking in hermes bundle #83359 makes identical babel.config.js and metro.config.js changes to previously-reverted PR Cleanup platform specifics from hermes build #80110
• PR Enable platform tree shaking in hermes bundle #83359 QA steps explicitly mention testing tag import to avoid regression, suggesting known risk
• Issue affects Android App platform specifically, consistent with native bundle changes

Verification

• Affected component: /home/runner/_work/App/App/src/components/ImportSpreadsheet.tsx
• Dynamic import at line 104: import('xlsx') - this is the import affected by babel/metro config changes
• Changes in PR Enable platform tree shaking in hermes bundle #83359:
  • metro.config.js line 38: Added experimentalImportSupport: true
  • babel.config.js line 66: Added disableImportExportTransform: true to React Native preset
• Confirmed: Only one file in the codebase uses dynamic import of xlsx library (ImportSpreadsheet.tsx)

Root Cause

The babel/metro configuration changes enable platform tree shaking but break dynamic imports on Android native builds. When disableImportExportTransform: true is set with experimentalImportSupport: true, Metro handles ES6 imports differently, which causes the dynamic import('xlsx') call to fail at runtime on Android.

The xlsx library is dynamically imported to reduce initial bundle size. The tree shaking configuration changes how Metro processes this dynamic import, resulting in the import failing silently or the xlsx module being unavailable when the import resolves, causing the "import failed" error when users try to upload tag spreadsheets.

History

1. PR Cleanup platform specifics from hermes build #80110 (Jan 2026): First attempt at platform tree shaking - caused tag import regression
2. Issue Tags - Import multi-level tags to workspace is failed #80844: Multi-level tags import failed - identical symptoms to current issue
3. PR [CP Staging] Revert "Cleanup platform specifics from hermes build" #80984 (Jan 2026): Reverted Cleanup platform specifics from hermes build #80110 to fix the regression
4. PR Enable platform tree shaking in hermes bundle #83359 (Mar 2026): Re-introduced identical changes - same regression has reoccurred
5. Issue Android - Tags - Multi level tags file cannot be imported #84969: Current issue - same failure pattern

The PR description for #83359 states "What is NOT changed (vs reverted PR 80110)" but the core babel/metro changes that caused the original regression are still present.

[MelvinBot]

Proposal

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

Multi-level tag import fails on native (Android/iOS) in staging after PR #83359 was merged. Users can pick and parse a CSV/TSV file, configure settings, and preview data, but tapping "Import" fails with "Cannot assign to property 'name' which has only a getter".

What is the root cause of that problem?

This is a known regression — the exact same failure previously occurred as issue #80844, caused by PR #80110, and was fixed by reverting those changes in PR #80984. PR #83359 re-introduced the identical babel.config.js and metro.config.js changes.

The two config changes are:

1. experimentalImportSupport: true in metro.config.js — causes Metro's import-export-plugin to handle import/export transforms and inject "use strict" into all ESM modules
2. disableImportExportTransform: true in babel.config.js — disables Babel's @babel/plugin-transform-modules-commonjs, so ESM files keep their import/export syntax for Metro to process

Previously, Babel converted all ESM modules to CommonJS (sloppy mode). Now, Metro preserves ESM and injects strict mode. React Native's File class (node_modules/react-native/Libraries/Blob/File.js:43-46) defines name as a getter-only property (no setter). Somewhere in the API call chain for ImportMultiLevelTags, code assigns to file.name on a File instance. In sloppy mode this silently fails; in strict mode it throws TypeError: Cannot assign to property 'name' which has only a getter, causing the import to fail.

The error was confirmed in issue #80844 with this log:

[alrt] ENSURE_BUGBOT unknown API request error caught while processing request -
{"message":"Cannot assign to property 'name' which has only a getter",
 "request":{"command":"ImportMultiLevelTags",...}}

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

Immediate fix (deploy blocker): Revert PR #83359 — this is the same fix that resolved issue #80844 via PR #80984.

Permanent fix (for re-enabling platform tree shaking later): Before re-attempting these config changes, the underlying strict mode incompatibility must be fixed. The File class's name property needs either:

• A setter added to File.name in React Native (upstream fix), or
• The code in the API/networking chain that assigns to file.name needs to be identified and fixed to avoid the assignment

The multi-level tag import flow is in src/libs/actions/Policy/Tag.ts:891-907 (importMultiLevelTags), which calls readFileAsync to create a File object and sends it via API.write. The File object passes through src/libs/prepareRequestPayload/index.native.ts and React Native's FormData.getParts() before being sent via XHR.

What alternative solutions did you explore? (Optional)

• Adding sideEffects: true override for xlsx — The xlsx package declares "sideEffects": false in its package.json, but since Metro resolves to the CJS entry point (xlsx.js), not the ESM one (xlsx.mjs), this is not the direct cause.
• Patching Metro's strict mode injection — Could exclude certain modules from strict mode injection, but this would be fragile and mask the underlying issue.
• Fixing only the affected code path — Would require identifying the exact line that assigns to file.name in the transform chain (possibly deep in React Native internals or a dependency affected by the module transform change). This is the right long-term approach but requires more investigation time than a deploy blocker allows.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.