Workspace - Duplicate default rate after copying settings, error when creating distance

[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.3.91-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: #91241
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Create two workspaces.
• Enable Distance rates in both workspace.

1. Go to staging.new.expensify.com
2. Go to Workspaces.
3. Click 3-dot menu on any workspace > Copy settings.
4. Select another workspace > Next.
5. Select Distance rates > Next.
6. Click Copy settings.
7. Open the workspace which has the settings copied > Distance rates.
   → Default rate appears twice.
8. Go to workspace chat (workspace with settings copied).
9. Create a distance expense.
10. Open the distance expense.
    → Error shows up.

Expected Result:

In Step 7, default rate will not be duplicated after copying settings.

Actual Result:

In Step 7, default rate is duplicated after copying settings.
In Step 10, error shows up after creating distance expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169336_1780384297210.9.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @ishpaul777

[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/06ce392777bc76bd58c57d104abd0a648b5169ebe0df43a780e90865838ae120

[melvin-bot]

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

[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 (duplicate default rate): This is a backend issue, not an App-repo bug — the fix requires changes outside this repository.

The App side of the "Copy settings" flow only sends policyID, policyIDList and parts to the server (CopyPolicySettings.ts:317-323) — it does not send any rate data. The server reconstructs and persists the copied distance rates itself. The App's optimistic update replaces the target workspace's distance-unit rates wholesale (CopyPolicySettings.ts:208-218), so it would show a single rate. The duplicate "Default Rate" only appears after the server response lands, which means the server-side copy is appending the source workspace's default rate to the target's existing rates instead of replacing/de-duplicating them.

Distance-expense error (Step 10): This is a downstream consequence of the corrupted data. When an expense is created, the default rate is chosen by sorting the unit's rates and picking the first (DistanceRequestUtils.ts:84-99). With two near-identical default rates, the expense ends up referencing an inconsistent rate, which surfaces the error on open — the same class of symptom as #90807.

Recommended next step: Because the duplication originates server-side, this needs an internal engineer with backend access to fix the CopyPolicySettings copy logic so that copying distance rates replaces (or de-duplicates) the target's existing rates rather than appending to them.

Investigation details & deploy-blocker mitigation

Why it's not a frontend bug:

• Wire payload contains no rate data — only policyID/policyIDList/parts (CopyPolicySettings.ts:317-323). The server owns the rate-copy logic.
• The optimistic write spreads the source distance unit under the target's existing customUnitID, which overwrites the rates map (CopyPolicySettings.ts:80-87). So the optimistic UI shows one rate; two rates can only come from the persisted server state.

Mitigation while the backend fix is prepared: The feature is gated behind the BULK_EDIT_WORKSPACES beta (WorkspacesListPage.tsx:383), and the only thing that dispatches the copy is the confirm page added in #91241 (CopyPolicySettingsConfirmPage.tsx:67). Reverting #91241 (or disabling the beta) removes the user-facing entry point and would unblock the deploy, but it does not fix the underlying backend duplication.

Confidence: Medium. The reasoning that the duplicate must originate server-side is solid (the optimistic frontend replaces rates and the wire payload carries no rate data), but I could not read the backend copy logic directly to confirm the exact merge behavior, nor confirm via production logs.

Possibly related (same feature area):

• [$250] [Sentry: APP-DWR] Web – Crash in Copy Policy Settings when a tag group has no tags: Cannot convert undefined or null to object #91965 — another Copy Policy Settings crash (empty tag group).
• [Due for payment 2026-06-02] [$250] Distance - After deleting a distance rate, the error appears only when opening the expense #90807 — distance error appears only when opening the expense after a rate change (same error-symptom mechanism).

---

Next Steps: This requires a backend fix by an internal engineer (the App repo can't address it). Reply with @MelvinBot <feedback> to refine this analysis.