[Bulk workspace edits] Handle async copy failure in the Copy Policy Settings progress modal

[MelvinBot]

Problem

Follow-up from #91368 (Copy Policy Settings progress modal).

The bulk copy runs asynchronously on the backend (BWM). When the job fails, the backend pushes state: 'failed' to the nvp_bulkPolicyCopySettings NVP — but the progress modal never reads that state. It only checks for 'complete' at CopyPolicySettingsProgressModal.tsx:26, and 'failed' is declared in the type but handled nowhere (CopyPolicySettingsNVP.ts:2).

As a result, on async failure the modal sits on "Copy in progress…" indefinitely with no error indication. The user's only escape is "Let me know when it's done" → "Dismiss", and they're never told the copy failed.

Note: the synchronous API failure is already covered (failureData resets currentStep to null and surfaces an RBR on the workspace rows). This issue is specifically about the async backend failure that arrives after the synchronous call has already succeeded.

Proposed handling

Add a failure state to the modal driven by nvp_bulkPolicyCopySettings.state === 'failed':

• If the user did NOT request a Concierge notification (still on the in-progress modal, shouldSendToConcierge: false): show a failure state with a Try again action. COPY_POLICY_SETTINGS still holds sourcePolicyID, targetPolicyIDs, and parts (CopyPolicySettings.ts:4-12), so we can re-fire copyPolicySettings() directly from the modal — no need to send the user back through the 3-step flow.
• If the user DID request a notification (shouldSendToConcierge: true): define the expected behavior for this case as well (e.g. surface the failure via Concierge and/or an RBR rather than the modal, since the user may have navigated away).

Copy/localization for the failure state will need to be added to src/languages/*.

Origin

Surfaced during final review of #91368 — see #91368 (comment).

Issue Owner

Current Issue Owner: @shubham1206agra

[fedirjh]

• show a failure state with a Try again action. COPY_POLICY_SETTINGS still holds sourcePolicyID, targetPolicyIDs, and parts (CopyPolicySettings.ts:4-12), so we can re-fire copyPolicySettings() directly from the modal — no need to send the user back through the 3-step flow.

@ishpaul777 @dannymcclain I'm wondering about the UX: if the copy encounters an error and the user attempts to copy again, they'll probably face the same error and get stuck in a loop of retry attempts. Is this the intended outcome?

• If the user DID request a notification (shouldSendToConcierge: true): define the expected behavior for this case as well (e.g. surface the failure via Concierge and/or an RBR rather than the modal, since the user may have navigated away).

@ishpaul777 Should this be handled on the backend?

[dannymcclain]

I'm wondering about the IX: if the copy encounters an error and the user attempts to copy again, they'll probably face the same error and get stuck in a loop of retry attempts. Is this the intended outcome?

We certainly don't want them to get stuck in an infinite fail loop. So what's the actual solution? How do they get it to work?

[ishpaul777]

@ishpaul777 Should this be handled on the backend?

Yes, I can handle that as part of https://github.com/Expensify/Expensify/issues/644573.

I'm wondering about the UX: if the copy encounters an error and the user attempts to copy again, they'll probably face the same error and get stuck in a loop of retry attempts. Is this the intended outcome?

I agree it's not ideal that a retry could result in the same failure if the underlying issue persists. One possible improvement would be to track whether the user has already retried once and, if the operation fails again, avoid showing the "Try again" action. That said, I'd defer to the design team on the expected retry experience

[dannymcclain]

@Expensify/design any other thoughts here?

I feel like if we don't let them retry, what do we show them? "Sorry it didn't work. Tough luck."? Like do we know what went wrong/if there's something they can do to try again successfully? I'm just not sure what the technical aspects of it are—but I'd like for us to give the user some kind of "out".

[shawnborton]

Yeah, I have similar feelings. If there is an error, how do we fix the error?

[fedirjh]

@dannymcclain @shawnborton — Quick context on how this works on the backend:

The bulk copy runs as a Bedrock job (BWM) with built-in retry logic. Transient failures (timeouts, temporary server issues) are automatically retried before the job gives up.

If state: 'failed' is pushed to the client, it means:

• Retries were already exhausted
• The failure is almost certainly permanent

Currently the backend only sets state: 'failed' — no error details are surfaced. The frontend can't tell the user what went wrong.

Proposal:

1. Backend change: When the BWM job fails, use Onyx::handleException() to merge the error into the policy's Onyx key — same pattern we use everywhere else for RBR errors (e.g., member removal failures, category errors, card assignment errors)
2. Frontend: On state === 'failed', dismiss the modal. The error appears as an RBR on the affected workspace row(s) — consistent with how sync failures work today
3. User sees the red dot, taps it, understands the issue (e.g., "No admin access to Workspace X"), and can retry with a corrected selection

Why this works:

• Reuses existing RBR error pattern — no new UI needed
• User gets actionable context
• Modal doesn't need a custom failure state — just dismiss and let RBR handle it

What do you think?

[dubielzyk-expensify]

User sees the red dot, taps it, understands the issue (e.g., "No admin access to Workspace X"), and can retry with a corrected selection

I think the alternative would be dismissing the confirmation dialog and hitting them with another dialog that says "Copy failed. You don't have admin access to Workspace X. Please do X and try again".

I don't think RBR is bad, but just wondering if it's a bit more expected to get an actual dialog error given the user took an action. I think I'm fine either way and curious what the other designers think