[Due for payment 2026-09-01] [$250] Button "Delete workspace" does not work if pressed again after an error occurs

[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.36-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: #95640
Email or phone of affected tester (no customers): applausetester+071726dr010@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 17 Pro / 26.5.2
App Component: Workspace Settings

Action Performed:

Precondition:

1. Login with new expensifail account
2. Create new workspace
3. Set Expensify card to Enable
4. Add Expensify card

Steps:

1. Open Expensify App on iOS
2. Login with account from Precondition
3. Go to Account > Troubleshoot > Clear cache and restart > Reset and refresh.
4. Go to Workspaces tab.
5. Click 3-dot menu on the workspace with Expensify Card > Delete workspace > Delete.
6. Verify that the error modal shows "Your company still has Expensify Cards. Please reach out to Concierge to remove them."
7. Open workspace settings > Expensify Cards.
8. Go to Workspaces tab again
9. Click 3-dot menu on the workspace with Expensify Card > Delete workspace > Delete.
10. Verify that the error modal shows "Your company still has Expensify Cards. Please reach out to Concierge to remove them."

Expected Result:

"Delete" button works correctly if pressed again after a workspace deletion error occurs.

Actual Result:

"Delete" button stops working if pressed again after a workspace deletion error occurs.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210413_1784258082388.95640-iOS-fail.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077964488087778371
• Upwork Job ID: 2077964488087778371
• Last Price Increase: 2026-07-17

Issue Owner

Current Issue Owner: @shubham1206agra

[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/5f9ab2edd26b58dd869ae019b70e04048dc1ba2f4eaf6e65a59e641aca255445

[MelvinBot]

Issue Analysis

Root Cause (medium confidence): The retry fails inside the reworked DeleteWorkspaceFlow. When you confirm deletion, the confirm modal is not closed — ConfirmModalWrapper calls resolveModal and leaves the modal open in a loading state (ConfirmModalWrapper.tsx:32-39), because continueDeleteWorkspace passes isConfirmLoading (DeleteWorkspaceFlow.tsx:205). Closing that modal and surfacing the "still has Expensify Cards" error is then done only by an effect that fires on an isPendingDelete true → false transition detected via usePrevious (DeleteWorkspaceFlow.tsx:272-294).

On the second attempt that transition is not reliably observed, so the effect never runs: the confirm modal never closes / the error modal never reopens, and the button appears dead. This flow is brand new (reworked in Expensify/App#95640, merged 2026-07-16 — one day before this report, and the same "open Expensify Cards then retry" scenario it targeted), so this is a regression in that rework.

Recommended Fix: Don't rely solely on the usePrevious(isPendingDelete) transition to close the confirm modal and show the error. For the online path, drive it deterministically from the delete result instead of an implicit re-render transition — e.g. have deleteWorkspace resolve/reject and, in the .then of continueDeleteWorkspace, closeModal() then branch to showDeleteWorkspaceErrorModal() / showGenericDeleteWorkspaceErrorModal() / onDeleteComplete() based on the outcome, mirroring the offline branch that already does this (DeleteWorkspaceFlow.tsx:232-238). This removes the dependence on catching a fleeting Onyx pendingAction transition that a second attempt can miss.

Investigation details & evidence chain

Reproduction path traced:

1. WorkspacesListPage mounts the flow only while deleting, keyed by workspace: WorkspacesListPage.tsx:257-263. onDismiss sets policyIDToDelete back to undefined.
2. Confirm modal is shown via the global modal system with isConfirmLoading set (DeleteWorkspaceFlow.tsx:199-205). Because isConfirmLoading !== undefined, tapping Delete keeps the modal open (resolveModal) and only starts the async delete.
3. Server rejects (workspace has active Expensify Cards) → failureData sets pendingAction: null (Policy.ts:524-531) and the server sets the error message.
4. The transition effect closes the confirm modal and opens the error modal (DeleteWorkspaceFlow.tsx:272-294). Dismissing it calls dismissWorkspaceError + onDismiss, unmounting the flow. On the second attempt the same sequence must re-fire, but the true → false pendingAction transition is fragile (optimistic + failure Onyx merges landing in one render, or the value not re-observed as true) — if it isn't caught, the confirm modal is left stuck loading and nothing else happens.

Alternative hypotheses considered (not ruled out without a runtime repro):

• The second delete never re-mounts the flow because onDismiss (→ setPolicyIDToDelete(undefined)) didn't fire when the first error modal was dismissed, so re-selecting the same workspace is a no-op (same key, no state change).
• On iOS, onModalHide on the error ConfirmModal not firing, leaving the global modal promise unresolved.

Both share the same fix direction: make the flow's close/dismiss deterministic rather than dependent on an implicit transition.

I was not able to run the iOS build to confirm which of these fires, so this is medium confidence — the subsystem and regression window are solid, the exact failing line needs a runtime repro.

Related: Expensify/App#94408 is the sibling bug in this same flow that PR #95640 fixed; no existing issue covers this "button stops working on retry" symptom.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96369) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

On iOS, deleting a workspace that still has an Expensify Card assigned correctly shows the "Your company still has Expensify Cards..." error modal the first time. After that error is shown, if the user navigates away (e.g. opens Workspace Settings > Expensify Cards) instead of tapping the error modal's confirm button, and then comes back to the Workspaces tab and tries "Delete workspace" again, nothing happens at all — no confirmation modal, no error modal, the "Delete" action is completely unresponsive.

What is the root cause of that problem?

DeleteWorkspaceFlow is only mounted while WorkspacesListPage holds a truthy policyIDToDelete in state, and it is keyed by that same id:

{!!policyIDToDelete && (
    <DeleteWorkspaceFlow key={policyIDToDelete} policyID={policyIDToDelete} onDismiss={() => setPolicyIDToDelete(undefined)} />
)}

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 257 to 263 in 0e8d4d7

	{!!policyIDToDelete && (
	<DeleteWorkspaceFlow
	key={policyIDToDelete}
	policyID={policyIDToDelete}
	onDismiss={() => setPolicyIDToDelete(undefined)}
	/>
	)}

Clicking "Delete workspace" in the 3-dot menu (WorkspaceRowThreeDotsMenu.tsx L149-156) simply calls onDeleteWorkspace(item.policyID), i.e. setPolicyIDToDelete(policyID). Inside DeleteWorkspaceFlow, the confirmation/deletion flow is only kicked off once, guarded by a ref:

const hasStartedRef = useRef(false);
useEffect(() => {
    if (hasStartedRef.current || isLoadingData) return;
    hasStartedRef.current = true;
    ...
    continueDeleteWorkspace();
});

App/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx

Lines 245 to 270 in 0e8d4d7

	const hasStartedRef = useRef(false);
	useEffect(() => {
	if (hasStartedRef.current || isLoadingData) {
	return;
	}
	hasStartedRef.current = true;
	if (shouldBlockWorkspaceDeletionForInvoicifyUser(isSubscriptionTypeOfInvoicing(privateSubscription?.type), policies, policyID, session?.accountID)) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.SUBSCRIPTION_DOWNGRADE_BLOCKED.path));
	onDismiss();
	return;
	}
	if (shouldBlockDeletion()) {
	// The outstanding balance modal is now visible and will call onDismiss when it is closed.
	return;
	}
	if (shouldCalculateBillNewDot) {
	setIsDeletingPaidWorkspace(true);
	calculateBillNewDot();
	return;
	}
	continueDeleteWorkspace();
	});

The only way policyIDToDelete is ever reset to undefined (which unmounts DeleteWorkspaceFlow and would give a fresh hasStartedRef on the next attempt) is via dismissDeleteWorkspaceFlow() → onDismiss(), which is invoked from the .then() of showConfirmModal(...) inside showDeleteWorkspaceErrorModal(). That .then() only fires when the user explicitly presses a button on the error modal; it is never invoked just because the screen loses focus. When the user instead navigates to "Workspace Settings > Expensify Cards" without pressing the error modal's button, WorkspacesListPage stays mounted underneath (RHP is pushed on top), isFocused goes false, but nothing forces dismissDeleteWorkspaceFlow() to run — the !isFocused early-return only exists as a guard at the top of showDeleteWorkspaceErrorModal/showGenericDeleteWorkspaceErrorModal, which is only consulted before a new invocation, not while the screen is losing focus with the modal already open. So policyIDToDelete is left holding the same policy id it already had. When the user comes back to the Workspaces tab and taps "Delete workspace" on the same row again, setPolicyIDToDelete(policyID) is called with an unchanged value — React bails out the update, DeleteWorkspaceFlow never remounts, and its stale hasStartedRef.current === true makes the mount effect return immediately without ever calling continueDeleteWorkspace() again. No confirmation modal, no error modal — the button appears completely dead, exactly as reported.

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

DeleteWorkspaceFlow already tracks isFocused via useIsFocused() and already has dismissDeleteWorkspaceFlow as the single correct cleanup path (it clears the policy's delete error via dismissWorkspaceError and calls onDismiss() to reset policyIDToDelete). The fix is to make that cleanup run whenever the flow's screen loses focus, not only when the user explicitly presses a modal button, so a subsequent tap on "Delete workspace" always starts from a clean, remounted flow:

useEffect(() => {
    if (isFocused) {
        return;
    }
    dismissDeleteWorkspaceFlow();
}, [isFocused, dismissDeleteWorkspaceFlow]);

This reuses the exact same dismissal path that already works correctly for the "press the error modal's confirm button" case, so policyIDToDelete is guaranteed to be reset to undefined (unmounting DeleteWorkspaceFlow and its stale hasStartedRef) the moment the user navigates away, regardless of whether they interacted with the modal. When the user returns and retriggers deletion, a brand-new DeleteWorkspaceFlow instance mounts and continueDeleteWorkspace() runs again as expected.

What alternative solutions did you explore? (Optional)

An alternative is to change WorkspaceRowThreeDotsMenu's "Delete workspace" onSelected to force setPolicyIDToDelete(undefined) before re-setting the id (e.g. via a microtask/requestAnimationFrame) so React always sees a state transition and remounts DeleteWorkspaceFlow. This was rejected because it treats the symptom at the click site rather than the actual leak (the flow never cleaning up on blur), and it would still leave the stale, non-reset policy.errors/pendingAction handling to chance instead of routing through the existing dismissWorkspaceError cleanup.

[ahmdshrif]

Proposal

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

After a workspace delete fails with an error, pressing "Delete workspace" a second time does nothing — the delete confirmation button no longer responds, so the user can't retry the deletion.

What is the root cause of that problem?

When a delete errors, the policy is left with pendingAction === RED_BRICK_ROAD_PENDING_ACTION.DELETE. On the next attempt DeleteWorkspaceFlow re-mounts and computes isPendingDelete from that stale pendingAction, so it is already true:

• App/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx

  Lines 115 to 116 in 0e8d4d7

  	const isPendingDelete = isPendingDeletePolicy(policy);
  	const prevIsPendingDelete = usePrevious(isPendingDelete);

The re-opened confirm modal is then rendered with isConfirmLoading: isPendingDelete, i.e. true, so the confirm button is stuck in a permanent loading/disabled state and can't be clicked — the button "does not work":

• App/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx

  Line 205 in 0e8d4d7

  ...(hasDeleteWorkspaceExpensifyCardsError ? {} : {isConfirmLoading: isPendingDelete}),

The error-recovery effect can't rescue it either: its if (!prevIsPendingDelete || isPendingDelete) return; guard only runs on a fresh true → false transition, which never happens on a remount that starts with isPendingDelete === true (L277).

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

Clear the leftover delete pendingAction when the errored flow is dismissed so the next mount starts clean. dismissWorkspaceError already clears both pendingAction and errors via clearDeleteWorkspaceError, but only when it is passed pendingAction === DELETE. Ensure the errored-delete cleanup always routes through that path (i.e. pass/force the DELETE pendingAction), and/or don't gate isConfirmLoading on a pre-existing pendingAction so a stale value can't lock the confirm button:

• App/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx

  Line 205 in 0e8d4d7

  ...(hasDeleteWorkspaceExpensifyCardsError ? {} : {isConfirmLoading: isPendingDelete}),

Regression check: confirm the button still shows its loading spinner during a genuine in-flight delete, and that a normal (non-errored) delete and the offline path are unaffected.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The delete flow uses the global confirmation-modal stack for both the initial asynchronous confirmation and the subsequent error. The initial modal resolves without closing so that it can show its loading state; when the API failure clears pendingAction, the effect closes that modal and immediately pushes another global modal for the error in the same render cycle.

App/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx

Lines 199 to 239 in 0e8d4d7

	showConfirmModal({
	title: translate('workspace.common.delete'),
	prompt: hasCardFeedOrExpensifyCard ? translate('workspace.common.deleteWithCardsConfirmation') : translate('workspace.common.deleteConfirmation'),
	confirmText: translate('common.delete'),
	cancelText: translate('common.cancel'),
	danger: true,
	...(hasDeleteWorkspaceExpensifyCardsError ? {} : {isConfirmLoading: isPendingDelete}),
	}).then((result) => {
	if (!policyName || result.action !== ModalActions.CONFIRM) {
	onDismiss();
	return;
	}
	deleteWorkspace({
	policies,
	policyID,
	activePolicyID,
	policyName,
	lastAccessedWorkspacePolicyID,
	policyCardFeeds: defaultCardFeeds,
	lastSelectedFeed,
	lastSelectedExpensifyCardFeed,
	reportsToArchive,
	transactionViolations,
	reimbursementAccountError,
	lastUsedPaymentMethods: lastPaymentMethod,
	localeCompare,
	personalPolicyID,
	hasDeleteWorkspaceExpensifyCardsError,
	currentUserAccountID: session?.accountID ?? CONST.DEFAULT_NUMBER_ID,
	accountIDToLogin: accountIDToLogin ?? {},
	});
	if (hasDeleteWorkspaceExpensifyCardsError) {
	showDeleteWorkspaceErrorModal();
	} else if (isOffline) {
	closeModal();
	onDeleteComplete?.();
	onDismiss();
	}
	});

App/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx

Lines 272 to 290 in 0e8d4d7

	useEffect(() => {
	if (isOffline) {
	return;
	}
	if (!prevIsPendingDelete || isPendingDelete) {
	return;
	}
	closeModal();
	if (policyLatestErrorMessage && (hasExpensifyCardsEnabledOnWorkspace || hasTravelInvoicingEnabledOnWorkspace)) {
	showDeleteWorkspaceErrorModal();
	return;
	}
	if (policyLatestErrorMessage) {
	showGenericDeleteWorkspaceErrorModal(policyLatestErrorMessage);
	return;

On native iOS this overlapping global-modal transition can leave the mounted DeleteWorkspaceFlow/modal lifecycle latched after the error. The next selection targets the same mounted flow, whose hasStartedRef has already been set, so it does not start another deletion attempt.

App/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx

Lines 244 to 270 in 0e8d4d7

	// Runs the pre-deletion checks and opens the confirmation modal once all the Onyx data the flow depends on has loaded.
	const hasStartedRef = useRef(false);
	useEffect(() => {
	if (hasStartedRef.current || isLoadingData) {
	return;
	}
	hasStartedRef.current = true;
	if (shouldBlockWorkspaceDeletionForInvoicifyUser(isSubscriptionTypeOfInvoicing(privateSubscription?.type), policies, policyID, session?.accountID)) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.SUBSCRIPTION_DOWNGRADE_BLOCKED.path));
	onDismiss();
	return;
	}
	if (shouldBlockDeletion()) {
	// The outstanding balance modal is now visible and will call onDismiss when it is closed.
	return;
	}
	if (shouldCalculateBillNewDot) {
	setIsDeletingPaidWorkspace(true);
	calculateBillNewDot();
	return;
	}
	continueDeleteWorkspace();
	});

This was introduced by commit 8d3d91293f4 (Switch to useConfirmModal), which replaced the locally controlled error ConfirmModal. The removed code explicitly kept the error local to avoid stacking it with the global delete confirmation on mobile.

8d3d912

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

Keep the asynchronous delete confirmation in useConfirmModal, but restore a locally controlled error ConfirmModal inside DeleteWorkspaceFlow. Store the error prompt/message in local state when the offline guard or the online pending-delete transition reports a failure, close the global loading modal, and render the local error modal alongside outstandingBalanceModal. Its confirm, cancel, and Concierge-link handlers should clear the local error state, call dismissWorkspaceError(), and invoke onDismiss() so the flow always unmounts before another attempt.

This keeps the existing specialized Expensify Card/Travel copy and generic HTML/plain-text errors, while removing the close-and-immediately-push operation from the global modal stack. deleteWorkspace() itself should remain unchanged: its failure data already restores pendingAction to null, which is what drives the failure transition.

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

Lines 500 to 552 in 0e8d4d7

	// Restore the old report stateNum and statusNum
	const failureData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.REIMBURSEMENT_ACCOUNT
	| typeof ONYXKEYS.COLLECTION.POLICY
	| typeof ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER
	| typeof ONYXKEYS.COLLECTION.PRIVATE_EXPENSIFY_CARD_SETTINGS
	| typeof ONYXKEYS.COLLECTION.LAST_SELECTED_FEED
	| typeof ONYXKEYS.COLLECTION.LAST_SELECTED_EXPENSIFY_CARD_FEED
	| typeof ONYXKEYS.NVP_ACTIVE_POLICY_ID
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD
	| typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
	>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.REIMBURSEMENT_ACCOUNT,
	value: {
	errors: reimbursementAccountError ?? null,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.POLICY}${policyID}`,
	value: {
	avatarURL: policy?.avatarURL,
	pendingAction: null,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER}${workspaceAccountID}`,
	value: policyCardFeeds ?? null,
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.PRIVATE_EXPENSIFY_CARD_SETTINGS}${workspaceAccountID}`,
	value: {pendingAction: null},
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.LAST_SELECTED_FEED}${policyID}`,
	value: lastSelectedFeed ?? null,
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.LAST_SELECTED_EXPENSIFY_CARD_FEED}${policyID}`,
	value: lastSelectedExpensifyCardFeed ?? null,
	},
	];

DeleteWorkspaceFlow has two production call sites. WorkspacesListPage will clear policyIDToDelete through its existing onDismiss, and WorkspaceOverviewPage will clear isDeleteWorkspaceFlowVisible; both therefore receive a fresh flow/ref on the next attempt.

App/src/pages/workspace/WorkspacesListPage.tsx

Lines 257 to 263 in 0e8d4d7

	{!!policyIDToDelete && (
	<DeleteWorkspaceFlow
	key={policyIDToDelete}
	policyID={policyIDToDelete}
	onDismiss={() => setPolicyIDToDelete(undefined)}
	/>
	)}

App/src/pages/workspace/WorkspaceOverviewPage.tsx

Lines 456 to 464 in 0e8d4d7

	const modals = (
	<>
	{isDeleteWorkspaceFlowVisible && !!policyID && (
	<DeleteWorkspaceFlow
	key={policyID}
	policyID={policyID}
	onDismiss={() => setIsDeleteWorkspaceFlowVisible(false)}
	onDeleteComplete={goBackFromInvalidPolicy}
	/>

Test coverage:

• Add a DeleteWorkspaceFlow UI regression test that rejects an online delete with the Expensify Cards error, acknowledges the local error modal, remounts the flow, and verifies that confirming again invokes deleteWorkspace() a second time.
• Cover both WorkspacesListPage and WorkspaceOverviewPage dismissal callbacks, plus the generic-error and Travel-error branches.
• Verify that the offline Expensify Card guard still shows the error without putting the confirmation button into an async loading state.

What alternative solutions did you explore? (Optional)

I considered changing ModalProvider/ConfirmModalWrapper so an already-resolved async modal can be replaced in place or queued until its native hide transition completes. That would address the sequencing at the shared layer, but it changes promise and stack behavior for every useConfirmModal consumer. The failure is specific to chaining the workspace delete confirmation into another modal, and the prior local-error design already isolates that native transition safely, so the flow-level fix has a smaller regression surface.

[aswin-s]

Proposal

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

On iOS, after the "Delete workspace" flow shows the Expensify Cards error modal and the user dismisses it, clicking "Delete workspace > Delete" a second time on the same workspace does nothing — no confirmation modal appears. Expected: each click should re-open the confirmation modal and allow the user to attempt the delete again.

What is the root cause of that problem?

In src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx:281, the online error-handling effect calls closeModal() before showing the error modal. That closeModal resolves the in-flight continueDeleteWorkspace confirm-modal promise with result.action !== ModalActions.CONFIRM, which runs the fallback onDismiss() at line 208 — clearing policyIDToDelete in the parent (WorkspacesListPage.tsx:261) and unmounting DeleteWorkspaceFlow while the error modal is being shown. When the user then clicks Delete again on the same workspace, setPolicyIDToDelete(samePolicyID) re-mounts the flow, but the Onyx policy still carries the previous errors object, so the online error effect at line 272 fires immediately on the fresh mount (prevIsPendingDelete transitions correctly on remount) and re-shows the error modal instead of the confirmation modal — the delete button appears to "do nothing". The hasStartedRef guard at line 245–250 further ensures continueDeleteWorkspace() is only called once per mount, so nothing else can re-open the confirmation.

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

1. src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx:281 — remove the unconditional closeModal() in the post-delete effect, or gate it so it does not resolve the still-pending continueDeleteWorkspace confirm modal (only close if a confirm modal is not still awaiting user input for THIS flow).
2. src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx:122 — in hideDeleteWorkspaceErrorModal / dismissDeleteWorkspaceFlow, ensure the previous errors/pendingAction are fully cleared on the policy (via dismissWorkspaceError) BEFORE onDismiss runs, so a subsequent remount does not immediately re-enter the error effect at line 272.
3. [src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx:283](https://github.com/Expensify/App/blob/0e8d4d752a5485dc08e6f8715474889edfa42813/src/pages/workspace/deleteWorkspace/DeleteWorkspaceFlow.tsx#L283)–290 — when re-showing the error modal after a failed delete, first reset hasStartedRef.current = false (or route back through continueDeleteWorkspace) so subsequent user-triggered attempts within the same mount can re-open the confirmation modal, rather than being permanently gated by the start-effect ref.
4. [src/pages/workspace/WorkspacesListPage.tsx:257](https://github.com/Expensify/App/blob/0e8d4d752a5485dc08e6f8715474889edfa42813/src/pages/workspace/WorkspacesListPage.tsx#L257)–261 — as a defense in depth, force a fresh mount on each click by using a monotonically-increasing key (e.g. ${policyIDToDelete}-${attempt}) instead of policyIDToDelete alone, so re-clicking the same workspace always yields a clean flow instance.

What alternative solutions did you explore? (Optional)

[melvin-bot]

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

[melvin-bot]

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