94060 - Workspace - Indefinite loading when copying workspace settings to a collect workspace

[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.32-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94060
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11 / Chrome, Samsung Galaxy A06 / Android 16
App Component: Workspace Settings

Action Performed:

1. Sign in to staging.new.expensify.com as an admin of a Control workspace and at least one Collect workspace.
2. From the workspaces list, open the three-dot menu on the Control workspace and click Copy settings.
3. On Select workspaces, select a Collect workspace and tap Next.
4. On Select settings, select a non-Control features (e.g. Categories) and tap Next
5. Click Copy Settings

Expected Result:

The chosen setting is copied correctly

Actual Result:

The app keeps loading for a long time, and the settings are not copied.
When copying to a Control Workspace, loading ends quickly.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203886_1783609926693.Recording__307.1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @fedirjh

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

[melvin-bot]

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

[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 (Medium confidence): The copy-settings loading modal never resolves for Collect target workspaces because it waits for a server push that only arrives for Control targets.

The progress modal stays on the "copy in progress" spinner until the backend pushes nvp_bulkPolicyCopySettings.state = complete — see CopyPolicySettingsProgressModal.tsx:26-33. The frontend write deliberately does not clear the loading step on API success; it relies entirely on that NVP push to flip the modal to "All Set" — see CopyPolicySettings.ts:429-442.

This frontend path is plan-agnostic — it runs identically whether the target is Control or Collect. Since Control targets complete quickly and Collect targets hang forever, the divergence must be server-side: the CopyPolicySettings command isn't transitioning the bulk-copy NVP to complete for Collect (Team) target workspaces. PR #94060 newly removed the Control-only restriction and started allowing Collect targets, which is why this only surfaces now.

Recommended Fix: The fix is in the backend (the CopyPolicySettings command / its NVP completion push), which lives outside the App repo. This needs an internal engineer with access to the backend repo to confirm and fix why the completion NVP isn't pushed for Collect targets. It can't be fixed in Expensify/App.

Deploy-blocker mitigation (App-side): The fastest safe unblock is to revert PR #94060, which restores the previous Control-only restriction and removes the un-completed Collect code path until the backend is fixed.

Investigation details

Evidence chain:

1. copyPolicySettings() fires the CopyPolicySettings write with optimistic currentStep = LOADING and NVP state = IN_PROGRESS. successData clears only per-policy pendingFields/errors — it does not clear currentStep. Only failureData sets currentStep: null. (CopyPolicySettings.ts:429-449)
2. The modal shows "All Set" only when copyInProgressStep && isCopySettingsComplete, where isCopySettingsComplete is bulkPolicyCopySettings.state === COMPLETE — a value the server owns. (CopyPolicySettingsProgressModal.tsx:26-33)
3. Because the user sees an indefinite spinner (not the RBR error that failureData would surface), the command is not failing on the client — it's completing without the backend ever pushing state = complete for the Collect target.

Alternative explanations considered:

• A Control-only feature was selected for a Collect target — ruled out: the repro selects Categories, which Collect supports, and the Upgrade step re-gates Control-only features before copy anyway.
• Frontend branches on plan type in the completion path — ruled out: the completion logic reads only currentStep and the NVP state, with no plan/type check.

Not verified: I could not inspect the backend command or production logs from here, so the exact reason the NVP isn't pushed for Collect targets is inferred, not directly observed. An internal engineer should confirm in the backend.

---

Next Steps for Contributor+ team:
To fix: This is a backend issue — escalate to an internal engineer with backend-repo access to fix the missing NVP completion push for Collect targets.
To unblock the deploy now: Revert PR #94060.
To refine: @MelvinBot <your feedback>

[shubham1206agra]

@fedirjh Can you check BE for this?