[$250] Tag - Choose from file page is not displayed in collect WS when importing multilevel Tags

[lanitochka17]

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.73-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
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-28773/folder/13176676/41236544/1413059563?p=2
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 pro /Chrome
App Component: Workspace Settings

Action Performed:

Precondition: Have a collect WS

1. Navigate to staging.new.expensify.com
2. Navigate to the workspace settings of the collect policy
3. Click on tags
4. Add some tags
5. Click on the "More" dropdown button
6. Click on the "Import spreadsheet" option
7. Click on the "Multi-level of tags"
8. Click on the "Upgrade" button
9. Click on the "Got it Thanks" button
10. Click on the "Switch Tag Levels" button

Expected Result:

Import spreadsheet modal displayed with a "Choose file" button. (Control WS Behavior)

Actual Result:

Import tags modal still displayed with options "Single level of tags" and "Multi-level of tags" even if i choose "Multi-level of tag" already

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7153478_1778713162630.bandicam_2026-05-14_01-54-50-386.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059634580992290216
• Upwork Job ID: 2059634580992290216
• Last Price Increase: 2026-05-27

[MelvinBot]

Proposal

What is the root cause of that problem?

When a Collect workspace user clicks "Multi-level of tags" → upgrades → confirms "Switch Tag Levels", the navigation to the file picker is deferred via setNavigationActionToMicrotaskQueue (microtask → requestAnimationFrame). Meanwhile, the confirm modal's hideModal schedules setTimeout(0, () => history.back()) to clean up its browser history entry.

Because requestAnimationFrame fires after setTimeout(0), the modal's history.back() triggers a popstate event that React Navigation processes before the navigate call executes — the withInternalPopstate guard only protects the Popover component, not React Navigation's listener. This disrupts the navigation state, preventing the file picker from appearing.

The setNavigationActionToMicrotaskQueue is unnecessary here because cleanPolicyTags has no optimistic Onyx data — there's nothing to wait for before navigating. The isMultiLevelTags branch at line 166 correctly uses direct Navigation.navigate and does not have this bug.

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

In ImportTagsOptionsPage.tsx, replace Navigation.setNavigationActionToMicrotaskQueue with direct Navigation.navigate in both locations where cleanPolicyTags is followed by deferred navigation:

1. Line 185-191 (multi-level flow, startMultiLevelTagImportFlow): Replace the deferred navigation with direct Navigation.navigate, matching the pattern used at line 167-170.
2. Line 254-259 (single-level menu item onPress): Same change — replace the deferred navigation with direct Navigation.navigate.

This ensures the navigation pushes its history entry before the modal's setTimeout(0) history.back() fires, which is the intended design per the modal comment.

Related issues and investigation details

• Expensify/App#90463 — "Tags-Android-Click 'Switch Tag Levels' Import spreadsheet modal is not displayed" appears to be the same root cause on Android.

Timing breakdown:

1. Modal onModalHide fires → resolves confirm promise
2. cleanPolicyTags runs (API.write, no optimistic data)
3. setNavigationActionToMicrotaskQueue: schedules microtask → microtask resolves → schedules requestAnimationFrame
4. setTimeout(0) fires: history.back() triggers popstate
5. React Navigation processes popstate (no guard — isInternalPopstateInProgress is only checked in Popover)
6. requestAnimationFrame fires navigate — but navigation state is already disrupted

---

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.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

I traced the full upgrade-to-multi-level-tags flow for a Collect workspace and found two interconnected gaps.

Gap 1 — missing multiLevelTags case in goBack()
WorkspaceUpgradePage.tsx:99-128 (goBack() switch) has no case for CONST.UPGRADE_FEATURE_INTRO_MAPPING.multiLevelTags.id. After the user clicks "Got it" on the upgrade confirmation, goBack() falls to the default branch (Navigation.goBack(route.params.backTo)) and navigates back to ImportTagsOptionsPage. This is the entry point for the second gap.

Gap 2 — deferred navigation in startMultiLevelTagImportFlow stalls in the upgrade post-flow path
Back on ImportTagsOptionsPage, useFocusEffect at lines 203–212 fires and calls startMultiLevelTagImportFlow() because shouldRunPostUpgradeFlow = true (set before navigating to the upgrade page, line 280) and isControlPolicy(policy) = true (optimistic update from upgradeToCorporate sets policy.type = CORPORATE, Policy.ts:5616). The function reaches the !isMultiLevelTags branch (lines 175–194), shows the "Switch Tag Levels" confirmation modal, and on confirm executes Navigation.setNavigationActionToMicrotaskQueue(() => Navigation.navigate(WORKSPACE_TAGS_IMPORT)) at lines 185–190. setNavigationActionToMicrotaskQueue wraps the navigate call in Promise.resolve().then(() => requestAnimationFrame(...)) (setNavigationActionToMicrotaskQueue.ts:6-12). When that requestAnimationFrame fires, ImportTagsOptionsPage has just re-gained focus (the global confirm modal closing restored focus to the underlying screen), and the navigation to WORKSPACE_TAGS_IMPORT fails to push the screen — leaving the user on ImportTagsOptionsPage.

The contrast with a direct Control-WS tap on "Multi-level of tags": that path calls startMultiLevelTagImportFlow() synchronously from a user-initiated onPress, so the setNavigationActionToMicrotaskQueue fires from a clean, non-useFocusEffect context and works correctly.

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

The fix has two parts, both in src/pages/workspace/upgrade/WorkspaceUpgradePage.tsx:

1. Add multiLevelTags to goBack() (lines 99–128)
Add a case for CONST.UPGRADE_FEATURE_INTRO_MAPPING.multiLevelTags.id. In this case:

• Call setImportedSpreadsheetIsImportingMultiLevelTags(true) (already exported from src/libs/actions/Policy/Tag.ts:864) to ensure ImportTagsPage knows it is a multi-level import when it mounts.
• Call Navigation.navigate(ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID)) directly. This replaces the roundabout useFocusEffect + setNavigationActionToMicrotaskQueue path with a single, explicit navigation that mirrors how other features navigate post-upgrade (e.g., companyCards at line 120).

2. Clean up shouldRunPostUpgradeFlow state in ImportTagsOptionsPage.tsx
Since the post-upgrade navigation is now handled by goBack() in WorkspaceUpgradePage, the useFocusEffect block at lines 203–212 should no longer fire for the upgrade path. The setShouldRunPostUpgradeFlow(true) call at line 280 should be removed (or the useFocusEffect should guard more tightly) to prevent startMultiLevelTagImportFlow() from being called a second time when the user happens to re-focus ImportTagsOptionsPage under other conditions.

Scope: touches WorkspaceUpgradePage.tsx (add import for setImportedSpreadsheetIsImportingMultiLevelTags, add switch case in goBack()) and ImportTagsOptionsPage.tsx (remove setShouldRunPostUpgradeFlow(true) call and optionally the useFocusEffect block). No changes needed in ROUTES.ts, SCREENS.ts, ModalStackNavigators, or any action files. Web-only repro (Windows Chrome), but the fix applies to all platforms. No offline or optimistic-rollback impact since setImportedSpreadsheetIsImportingMultiLevelTags is a local Onyx merge with no API call.

What alternative solutions did you explore? (Optional)

Alternative: fix setNavigationActionToMicrotaskQueue call in startMultiLevelTagImportFlow
Replacing Navigation.setNavigationActionToMicrotaskQueue(() => Navigation.navigate(...)) at lines 185–190 of ImportTagsOptionsPage.tsx with a direct Navigation.navigate(...) would avoid the requestAnimationFrame timing gap. Rejected: setNavigationActionToMicrotaskQueue exists to let Onyx updates (setImportedSpreadsheetIsImportingMultiLevelTags at line 156) settle before ImportTagsPage mounts and reads the spreadsheet state. Removing it risks ImportTagsPage routing to the wrong goTo destination on slower devices. The goBack() fix avoids this concern entirely.

Alternative: keep existing useFocusEffect path but call Navigation.navigate instead of setNavigationActionToMicrotaskQueue
Would work but leaves the fragile shouldRunPostUpgradeFlow local-state + useFocusEffect mechanism in place for the upgrade flow, which is harder to reason about and is the root of the original timing issue. The goBack() approach matches how every other feature handles post-upgrade navigation.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-27 19:11:59 UTC.

Proposal

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

On a Collect workspace that already has single‑level tags, picking More → Import spreadsheet → Multi‑level of tags → Upgrade → Got it Thanks → Switch Tag Levels keeps the user on the Single level / Multi‑level picker instead of opening the Choose from file page.

What is the root cause of that problem?

The whole post‑upgrade hand‑off lives inside a useFocusEffect that was added in PR #64989 (commit 04cb952, "Redirect to multi‑level tag import after workspace upgrade").

When the Multi‑level of tags row is tapped on a Collect WS, the page only records intent and navigates to the upgrade screen:

App/src/pages/workspace/tags/ImportTagsOptionsPage.tsx

Lines 278 to 286 in 0eaf9f7

	onPress={() => {
	if (!isControlPolicy(policy)) {
	setShouldRunPostUpgradeFlow(true);
	Navigation.navigate(ROUTES.WORKSPACE_UPGRADE.getRoute(policyID, CONST.UPGRADE_FEATURE_INTRO_MAPPING.multiLevelTags.alias, Navigation.getActiveRoute()));
	return;
	}
	startMultiLevelTagImportFlow();
	}}
	/>

After the user clicks Got it Thanks, WorkspaceUpgradePage.goBack falls through to the default branch (the multiLevelTags feature isn't listed) and pops back to WORKSPACE_TAGS_IMPORT_OPTIONS:

App/src/pages/workspace/upgrade/WorkspaceUpgradePage.tsx

Lines 135 to 137 in 0eaf9f7

	default:
	return route.params.backTo ? Navigation.goBack(route.params.backTo) : Navigation.goBack();
	}

Back on the options page, the focus effect runs startMultiLevelTagImportFlow and immediately flips the flag off:

App/src/pages/workspace/tags/ImportTagsOptionsPage.tsx

Lines 203 to 212 in 0eaf9f7

	useFocusEffect(
	useCallback(() => {
	if (!shouldRunPostUpgradeFlow || !isControlPolicy(policy)) {
	return;
	}
	startMultiLevelTagImportFlow();
	setShouldRunPostUpgradeFlow(false);
	}, [shouldRunPostUpgradeFlow, policy, startMultiLevelTagImportFlow]),
	);

Because the workspace already has single‑level tags (hasVisibleTags && !isMultiLevelTags), the flow opens the global "Switch Tag Levels" confirm via useConfirmModal. The hook hard‑codes shouldHandleNavigationBack: true, so on web Modal/index.tsx calls window.history.pushState({shouldGoBack: true}) when the modal mounts, and on hide it queues a setTimeout(0, () => withInternalPopstate(window.history.back())):

App/src/hooks/useConfirmModal.ts

Lines 12 to 21 in 0eaf9f7

	const showConfirmModal = ({id, ...options}: ConfirmModalOptions) => {
	return context.showModal({
	component: ConfirmModalWrapper,
	id,
	props: {
	shouldHandleNavigationBack: true,
	...options,
	},
	});
	};

App/src/components/Modal/index.tsx

Lines 47 to 76 in 0eaf9f7

	const hideModal = () => {
	window.removeEventListener('popstate', handlePopState);
	if ((window.history.state as WindowState)?.shouldGoBack && shouldHandleNavigationBack) {
	onModalHide();
	// Defer history.back() so it runs after any pending navigation
	// callbacks (from onModalDidClose) have pushed their history entries.
	// This prevents the popstate from undoing navigations triggered by
	// menu item selection callbacks.
	setTimeout(() => {
	if (!(window.history.state as WindowState)?.shouldGoBack) {
	return;
	}
	withInternalPopstate(() => window.history.back());
	}, 0);
	} else {
	onModalHide();
	}
	};
	const showModal = () => {
	if (shouldHandleNavigationBack) {
	// Preserve React Navigation's state in the guard entry so that if
	// popstate fires for this entry, RN recognizes the current route
	// and does not perform an unexpected back navigation.
	const currentState = (window.history.state ?? {}) as WindowState;
	window.history.pushState({...currentState, shouldGoBack: true}, '', null);
	window.addEventListener('popstate', handlePopState);
	}
	onModalShow?.();
	};

Now look at the confirm branch in startMultiLevelTagImportFlow:

App/src/pages/workspace/tags/ImportTagsOptionsPage.tsx

Lines 175 to 194 in 0eaf9f7

	} else {
	const {action} = await showConfirmModal({
	title: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
	prompt: switchSingleToMultiLevelTagPrompt,
	confirmText: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
	cancelText: translate('common.cancel'),
	danger: true,
	});
	if (action === ModalActions.CONFIRM) {
	cleanPolicyTags(policyID);
	Navigation.setNavigationActionToMicrotaskQueue(() => {
	Navigation.navigate(
	isQuickSettingsFlow
	? ROUTES.SETTINGS_TAGS_IMPORT.getRoute(policyID, ROUTES.SETTINGS_TAGS_ROOT.getRoute(policyID, backTo))
	: ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID),
	);
	});
	} else {
	setImportedSpreadsheetIsImportingMultiLevelTags(false);
	}

After the user taps Switch Tag Levels the await showConfirmModal resolves only after onModalHide fires, which is the same call that schedules setTimeout(0, history.back). The confirm path then defers navigation through setNavigationActionToMicrotaskQueue → Promise.resolve().then(requestAnimationFrame) (added in d632377 "fix navigate to import page"). The resulting event ordering on web is:

1. microtask — await continuation runs cleanPolicyTags and queues another microtask via setNavigationActionToMicrotaskQueue.
2. microtask — schedules requestAnimationFrame(Navigation.navigate).
3. macrotask (setTimeout 0) — withInternalPopstate(window.history.back) fires, browser URL rewinds from the modal's pushed entry back to …/tags/import/import-options.
4. next frame (rAF) — Navigation.navigate(WORKSPACE_TAGS_IMPORT) finally calls linkTo and dispatches the PUSH to the RHP stack.

Step 3 lands between the await resolving and step 4. withInternalPopstate only flips the flag while the popstate listener is installed, and the browser dispatches popstate asynchronously — so the navigator/state↔URL sync from the modal's history.back() is processed after we have already mutated the RHP stack with PUSH WORKSPACE_TAGS_IMPORT. React Navigation's URL/state reconciliation then drops the pushed WORKSPACE_TAGS_IMPORT entry (the URL was rewound under the new state) and the visible screen stays at WORKSPACE_TAGS_IMPORT_OPTIONS. None of this happens in the direct‑click flow on an already‑Control workspace because there the setTimeout 0/rAF race doesn't coincide with a fresh goBack transition completing in the same tick.

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

Remove the timing race by skipping the setTimeout 0/history.back web‑history dance for this specific modal (we navigate forward immediately after confirm — the back‑guard is moot), and let setNavigationActionToMicrotaskQueue keep doing its only useful job (flushing Onyx writes before navigation):

-                const {action} = await showConfirmModal({
-                    title: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
-                    prompt: switchSingleToMultiLevelTagPrompt,
-                    confirmText: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
-                    cancelText: translate('common.cancel'),
-                    danger: true,
-                });
+                const {action} = await showConfirmModal({
+                    title: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
+                    prompt: switchSingleToMultiLevelTagPrompt,
+                    confirmText: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
+                    cancelText: translate('common.cancel'),
+                    danger: true,
+                    shouldHandleNavigationBack: false,
+                });

The same single‑word override is needed on the sibling overrideMultiTag confirm (lines 159‑165) and on the inline singleLevel row confirm (lines 245‑251) so the picker behaves the same whether the user taps Single level or Multi‑level, and whether they reached the page through the upgrade flow or by re‑opening it on an already‑Control workspace.

Files / platforms touched:

• src/pages/workspace/tags/ImportTagsOptionsPage.tsx only — 3 added lines, all inside existing showConfirmModal({...}) argument objects.
• No API/Onyx/Route changes; the regression is web‑only, but the prop is no‑op on native, so the patch is safe across platforms.
• policy?.requiresTag / isDisablingOrDeletingLastEnabledTag guard logic from the in‑flight PR for [Due for payment 2026-01-23] [$250] Workspace setting-Taxes page still shown when disable the taxes from other browser #75861 is untouched.

What alternative solutions did you explore? (Optional)

1. Drop setNavigationActionToMicrotaskQueue from the confirm branches and call Navigation.navigate synchronously. — Rejected: that wrapper was added in d632377 (fix navigate to import page) to flush setImportedSpreadsheetIsImportingMultiLevelTags/cleanPolicyTags Onyx writes before the destination renders. Removing it re‑introduces the original bug (target page mounts with stale Onyx).
2. Bypass the auto‑flow entirely by teaching WorkspaceUpgradePage.goBack to navigate directly to WORKSPACE_TAGS_IMPORT for the multiLevelTags feature and dropping shouldRunPostUpgradeFlow + the useFocusEffect. — Rejected because the "Switch Tag Levels" warning (the modal we'd skip) is the only place the user is told tags get wiped; silently cleanPolicyTags on a workspace with existing tags is a worse UX regression than the bug.
3. Wrap the confirm’s navigation in a second requestAnimationFrame to win the race against setTimeout(0). — Rejected because it papers over the cause and keeps the history.back happening after a pushState, which still leaves a phantom history entry one user‑initiated browser Back away from the wrong screen.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

When the user finishes the upgrade flow and confirms "Switch Tag Levels", the navigation to WORKSPACE_TAGS_IMPORT is wrapped in Navigation.setNavigationActionToMicrotaskQueue, which defers the Navigation.navigate call into a microtask → requestAnimationFrame:

https://github.com/Expensify/App/blob/main/src/libs/Navigation/helpers/setNavigationActionToMicrotaskQueue.ts#L1-L13

In parallel, useConfirmModal mounts the confirmation modal with shouldHandleNavigationBack: true by default (useConfirmModal.ts#L16-L19), which pushes a guard history entry on open and schedules a setTimeout(0) → window.history.back() on close to pop it:

https://github.com/Expensify/App/blob/main/src/components/Modal/index.tsx#L46-L63

After the user clicks "Switch Tag Levels", the close handler resolves the modal promise, handlePostConfirmTagSwitch runs, schedules navigation via rAF, and the modal's setTimeout(0) then fires history.back(). Because setTimeout(0) macrotasks run before the next paint while rAF waits for the paint, the popstate from history.back() is processed by React Navigation's linking listener first, restoring the navigator to WORKSPACE_TAGS_IMPORT_OPTIONS. The subsequent rAF Navigation.navigate(WORKSPACE_TAGS_IMPORT) then fires against a navigator state that has just been reset, and the route push is lost — the user remains on the options page.

The sibling branch handling already-multi-level overrides at ImportTagsOptionsPage.tsx#L166-L171 does not exhibit this bug because it calls Navigation.navigate synchronously inside the same microtask continuation, beating the modal's setTimeout(0) to the popstate handler.

setNavigationActionToMicrotaskQueue was originally added to give Onyx merges time to flush before route changes (#37785), but here cleanPolicyTags ships no optimisticData (Tag.ts#L859-L875) and the only relevant local Onyx write — setImportedSpreadsheetIsImportingMultiLevelTags(true) at the top of startMultiLevelTagImportFlow — has long since flushed by the time the user dismisses the confirm modal. There is nothing left to wait for.

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

In src/pages/workspace/tags/ImportTagsOptionsPage.tsx, drop the microtask wrapper inside handlePostConfirmTagSwitch so the navigate executes in the same microtask continuation as the modal-close await — exactly like the override branch at L166-L171:

 const handlePostConfirmTagSwitch = () => {
     cleanPolicyTags(policyID, policy?.requiresTag === true);
-    Navigation.setNavigationActionToMicrotaskQueue(() => {
-        Navigation.navigate(
-            isQuickSettingsFlow ? ROUTES.SETTINGS_TAGS_IMPORT.getRoute(policyID, ROUTES.SETTINGS_TAGS_ROOT.getRoute(policyID, backTo)) : ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID),
-        );
-    });
+    Navigation.navigate(
+        isQuickSettingsFlow ? ROUTES.SETTINGS_TAGS_IMPORT.getRoute(policyID, ROUTES.SETTINGS_TAGS_ROOT.getRoute(policyID, backTo)) : ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID),
+    );
 };

As a defense-in-depth measure (and to bring useConfirmModal usage in line with the member-import flow that already does this), also pass shouldHandleNavigationBack: false to the two showConfirmModal calls inside startMultiLevelTagImportFlow (the overrideMultiTagWarning at L158-L165 and the switchSingleToMultiLevelTagWarning at L169-L176) and the singleLevel MenuItem.onPress modal at L237-L244. These modals are short-lived confirmations that resolve directly into forward navigation — there is no meaningful state for the browser back button to dismiss into — so opting out of the history guard removes the popstate side-effect entirely.

The reverse switch case (single→multi already on Control) and the no-tags case at L182-L184 already use direct Navigation.navigate and are unaffected.

What alternative solutions did you explore? (Optional)

Move the navigation into WorkspaceUpgradePage.goBack() via a new multiLevelTags case — goBack() already handles per-feature post-upgrade navigation for companyCards, reportFields, etc. Adding a multi-level-tags case would let the upgrade page push the user straight to WORKSPACE_TAGS_IMPORT (or first to the confirm flow) and let us delete the shouldRunPostUpgradeFlow + useFocusEffect indirection in ImportTagsOptionsPage. Rejected as the primary fix: it doesn't address the race for the Control-WS direct path (same code, same race, just lands on the lucky side of the timing today), and the local setNavigationActionToMicrotaskQueue removal is a one-liner that fixes both paths with no API surface change.

Wrap the navigation in an extra setTimeout(0) instead of requestAnimationFrame — would put the navigate and the modal's history.back() in the same macrotask queue, but the modal's setTimeout is scheduled before ours (it runs inside the synchronous modal-hide callback while we're still awaiting), so we would still lose the race. Removing the deferral entirely is the only deterministic fix.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-27 13:56:01 UTC.

Proposal

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

On a Collect workspace with existing single-level tags, after the user picks "Multi-level of tags" → Upgrade → "Got it Thanks" → "Switch Tag Levels", the app should land on the "Choose file" import page (the Control workspace behavior). Instead, the user is dropped right back on the import options screen showing "Single level of tags" / "Multi-level of tags". The post-upgrade hand-off into the file picker is being lost.

What is the root cause of that problem?

The regression was introduced by the refactor in commit 83e4a461990 ("refactor ConfirmModal usage to useConfirmModal in workspace tags pages"), which swapped the JSX-mounted ConfirmModal for the promise-based useConfirmModal. With the old ConfirmModal, onConfirm ran synchronously inside the click handler and called Navigation.navigate(WORKSPACE_TAGS_IMPORT) immediately — there was no history.back / popstate interaction because the inline <ConfirmModal> never set shouldHandleNavigationBack. With useConfirmModal, the hook defaults shouldHandleNavigationBack: true on every modal, so each showConfirmModal call pushes a guard history entry via window.history.pushState({shouldGoBack: true}, '', null) on open, and on close hideModal defers a window.history.back() via setTimeout(0):

App/src/components/Modal/index.tsx

Lines 47 to 64 in 0f9a56c

	const hideModal = () => {
	window.removeEventListener('popstate', handlePopState);
	if ((window.history.state as WindowState)?.shouldGoBack && shouldHandleNavigationBack) {
	onModalHide();
	// Defer history.back() so it runs after any pending navigation
	// callbacks (from onModalDidClose) have pushed their history entries.
	// This prevents the popstate from undoing navigations triggered by
	// menu item selection callbacks.
	setTimeout(() => {
	if (!(window.history.state as WindowState)?.shouldGoBack) {
	return;
	}
	withInternalPopstate(() => window.history.back());
	}, 0);
	} else {
	onModalHide();
	}
	};

The new startMultiLevelTagImportFlow (lines 175–195) awaits the modal close, then schedules Navigation.navigate(WORKSPACE_TAGS_IMPORT) through Navigation.setNavigationActionToMicrotaskQueue, which itself defers to a requestAnimationFrame. The two side effects therefore race: the modal's setTimeout(0) macrotask fires history.back() (popping the guard entry), and the rAF-deferred Navigation.navigate pushes a new entry. When popstate from history.back() is then processed by React Navigation's useLinking listener, it sees a record for the prior entry and calls navigation.resetRoot(record.state) — restoring the navigator back to WORKSPACE_TAGS_IMPORT_OPTIONS and discarding the freshly pushed WORKSPACE_TAGS_IMPORT route. Net result: the user is stranded on the options page.

This bug only surfaces in the Collect-WS path because that is the only path that triggers startMultiLevelTagImportFlow from useFocusEffect after returning from upgrade — the Control-WS path also goes through the same modal, but in practice the Collect-WS post-upgrade entry has the extra shouldRunPostUpgradeFlow re-render churn around startMultiLevelTagImportFlow, and the rAF/setTimeout race lands on the losing side. The same class of regression was already acknowledged for member import in 1f49d0970f6 ("Fix member import crash and missing navigation after confirmation"), where the fix was to opt the confirmation modal out of shouldHandleNavigationBack and move the navigation out of the modal-close promise.

App/src/pages/workspace/tags/ImportTagsOptionsPage.tsx

Lines 183 to 194 in 0f9a56c

	if (action === ModalActions.CONFIRM) {
	cleanPolicyTags(policyID);
	Navigation.setNavigationActionToMicrotaskQueue(() => {
	Navigation.navigate(
	isQuickSettingsFlow
	? ROUTES.SETTINGS_TAGS_IMPORT.getRoute(policyID, ROUTES.SETTINGS_TAGS_ROOT.getRoute(policyID, backTo))
	: ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID),
	);
	});
	} else {
	setImportedSpreadsheetIsImportingMultiLevelTags(false);
	}

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

Override the default by passing shouldHandleNavigationBack: false to the two showConfirmModal calls inside startMultiLevelTagImportFlow in src/pages/workspace/tags/ImportTagsOptionsPage.tsx (the overrideMultiTagWarning call at lines 159–165 and the switchSingleToMultiLevelTagWarning call at lines 176–182), and apply the same override to the in-place singleLevel MenuItem.onPress modal at lines 245–251 so the behavior is consistent regardless of how the modal is entered. With shouldHandleNavigationBack: false, Modal.tsx skips the pushState/history.back() dance on open and close, so the only navigation action that touches history is the explicit Navigation.navigate(WORKSPACE_TAGS_IMPORT) call after cleanPolicyTags. The Navigation.setNavigationActionToMicrotaskQueue wrapper can stay — it was added to guarantee that cleanPolicyTags' Onyx writes flush before the route change — but it no longer races against a phantom popstate.

This fix is safe because the modal here is purely a confirmation that doesn't itself represent a navigable step (we don't want the browser back button to "close" the modal and stay on the same options page — there's nothing meaningful to go back to). shouldHandleNavigationBack exists to bridge the browser back button to modal dismissal, but for this flow the modal is short-lived and resolves directly into a forward navigation, so opting out matches the pre-refactor behavior exactly. Other call sites that need browser-back-to-close (e.g. the offline confirmation in WorkspaceTagsPage) keep the default and are unaffected.

What alternative solutions did you explore? (Optional)

We could instead pull Navigation.navigate out of the await continuation and pass it as a callback executed before the modal's exit animation starts — mirroring the member-import fix that moved navigation into closeImportPageAndModal. That works but requires restructuring useConfirmModal (or adding a beforeClose hook), whereas the shouldHandleNavigationBack: false override is a one-liner per call site that produces identical net behavior to the original <ConfirmModal> JSX usage.

[KJ21-ENG]

Proposal

Replaces my earlier proposal, which was withdrawn by ProposalPolice as a duplicate. This version narrows the fix to the Collect-to-Control continuation being consumed before the tag-cleanup/import-page transition settles; it does not rely on a WorkspaceUpgradePage special case or a modal-history-only change.

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

When a Collect workspace admin starts the multi-level tags import flow, upgrades to Control, and confirms the "Switch Tag Levels" warning, the app stays on the Import tags options page instead of opening the Import spreadsheet page with the Choose file button.

What is the root cause of that problem?

The Collect-to-Control continuation is stored in ImportTagsOptionsPage local state and is cleared before the resumed switch flow has actually completed.

For non-Control policies, tapping Multi-level tags sets shouldRunPostUpgradeFlow and opens WORKSPACE_UPGRADE with the current options route as backTo. Returning from upgrade to the options page is expected because the app still needs to run the normal multi-level import flow and, when single-level tags exist, show the destructive Switch Tag Levels confirmation.

The failure is in the resumed path after that return. On focus, ImportTagsOptionsPage calls startMultiLevelTagImportFlow() and immediately resets shouldRunPostUpgradeFlow to false:

App/src/pages/workspace/tags/ImportTagsOptionsPage.tsx

Lines 203 to 210 in 86565b9

	useFocusEffect(
	useCallback(() => {
	if (!shouldRunPostUpgradeFlow || !isControlPolicy(policy)) {
	return;
	}
	startMultiLevelTagImportFlow();
	setShouldRunPostUpgradeFlow(false);

Inside startMultiLevelTagImportFlow(), the single-level-to-multi-level branch confirms the switch, calls cleanPolicyTags(policyID), then schedules navigation to WORKSPACE_TAGS_IMPORT:

App/src/pages/workspace/tags/ImportTagsOptionsPage.tsx

Lines 155 to 199 in 86565b9

	const startMultiLevelTagImportFlow = useCallback(async () => {
	setImportedSpreadsheetIsImportingMultiLevelTags(true);
	if (hasVisibleTags) {
	if (isMultiLevelTags) {
	const {action} = await showConfirmModal({
	title: translate('workspace.tags.overrideMultiTagWarning.title'),
	prompt: overrideMultiTagPrompt,
	confirmText: translate('workspace.tags.overrideMultiTagWarning.title'),
	cancelText: translate('common.cancel'),
	danger: true,
	});
	if (action === ModalActions.CONFIRM) {
	Navigation.navigate(
	isQuickSettingsFlow
	? ROUTES.SETTINGS_TAGS_IMPORT.getRoute(policyID, ROUTES.SETTINGS_TAGS_ROOT.getRoute(policyID, backTo))
	: ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID),
	);
	} else {
	setImportedSpreadsheetIsImportingMultiLevelTags(false);
	}
	} else {
	const {action} = await showConfirmModal({
	title: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
	prompt: switchSingleToMultiLevelTagPrompt,
	confirmText: translate('workspace.tags.switchSingleToMultiLevelTagWarning.title'),
	cancelText: translate('common.cancel'),
	danger: true,
	});
	if (action === ModalActions.CONFIRM) {
	cleanPolicyTags(policyID);
	Navigation.setNavigationActionToMicrotaskQueue(() => {
	Navigation.navigate(
	isQuickSettingsFlow
	? ROUTES.SETTINGS_TAGS_IMPORT.getRoute(policyID, ROUTES.SETTINGS_TAGS_ROOT.getRoute(policyID, backTo))
	: ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID),
	);
	});
	} else {
	setImportedSpreadsheetIsImportingMultiLevelTags(false);
	}
	}
	} else {
	Navigation.navigate(
	isQuickSettingsFlow ? ROUTES.SETTINGS_TAGS_IMPORT.getRoute(policyID, ROUTES.SETTINGS_TAGS_ROOT.getRoute(policyID, backTo)) : ROUTES.WORKSPACE_TAGS_IMPORT.getRoute(policyID),
	);

But cleanPolicyTags() currently drops the API.write() promise and has no optimistic/success Onyx sequencing for the caller:

App/src/libs/actions/Policy/Tag.ts

Lines 849 to 852 in 86565b9

	function cleanPolicyTags(policyID: string) {
	// We do not have any optimistic data or success data for this command as this action cannot be done offline
	API.write(WRITE_COMMANDS.CLEAN_POLICY_TAGS, {policyID});
	}

In the reported flow, the cleanup removes the existing single-level tags and the options page re-renders, but the post-upgrade intent has already been consumed. If the first deferred navigation does not land during the upgrade/modal return sequence, the page no longer retries the now-direct hasVisibleTags === false path, so the user remains on the two-option Import tags page. The attached video frames match that: after Switch Tag Levels, the tag list is empty while the options page is still visible, and a later manual click reaches the Choose file page because there are no visible tags left.

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

Make the post-upgrade import continuation idempotent until the flow reaches the import page or the user cancels.

1. Change cleanPolicyTags(policyID) to return the API.write(WRITE_COMMANDS.CLEAN_POLICY_TAGS, {policyID}) promise.
2. In ImportTagsOptionsPage, extract a small navigateToTagsImport() helper so the direct branch, override branch, and switch branch all use the same final route.
3. In the switch-confirm branch, keep isImportingMultiLevelTags set, call cleanPolicyTags(policyID), and navigate in finally / after the returned promise settles. For the post-upgrade resume, use Navigation.navigate(route, {waitForTransition: true}) so the final route push is dispatched after the upgrade RHP return transition.
4. Move setShouldRunPostUpgradeFlow(false) out of the focus effect's immediate path. Reset it only after startMultiLevelTagImportFlow() resolves/cancels or after navigateToTagsImport() is dispatched. If a cleanup is already in flight, guard against opening a second confirmation; when the pending cleanup makes hasVisibleTags false, the same continuation should only run the direct navigation branch. That way, a focused options-page re-render cannot strand the user.

This keeps the existing Control workspace behavior, preserves the destructive confirmation before deleting existing tags, and only changes the sequencing of the Collect-to-Control resume path.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add focused coverage around ImportTagsOptionsPage or an extracted flow helper:

• Collect policy with one visible single-level tag: selecting Multi-level tags starts upgrade; after the policy becomes Control and the user confirms Switch Tag Levels, cleanPolicyTags is called and navigation reaches WORKSPACE_TAGS_IMPORT.
• Control policy with one visible single-level tag: selecting Multi-level tags and confirming Switch Tag Levels still cleans tags and navigates to WORKSPACE_TAGS_IMPORT.
• Control policy with no visible tags: selecting Multi-level tags navigates directly to WORKSPACE_TAGS_IMPORT without showing the destructive confirmation.

What alternative solutions did you explore? (Optional)

Adding a multiLevelTags special case in WorkspaceUpgradePage would route around the options page, but that page is where the app decides whether to show the Switch Tag Levels warning and clean existing tags. Jumping straight from the upgrade page to the import page risks bypassing that confirmation for workspaces that still have single-level tags.

Only changing the confirmation modal's browser-history handling could avoid one way the first navigation gets disrupted, but it leaves the Collect-specific continuation consumed before cleanup/navigation has settled. Keeping the continuation alive until the flow reaches the import page is the more direct guard for this reported failure.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022059634580992290216