[Due for payment 2026-05-22] [$250] Expense - "Rate not valid for this workspace" error, reappears after selecting a valid rate.

[mitarachim]

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.31.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-7606/folder/13176670/41237108/1228588679
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace with "Rules" enabled.
Prerequisite 2: Account has Self DM.

1. Open the staging.new.expensify.com website.
2. Navigate to Self DM.
3. Create a map distance expense.
4. Open the just created expense.
5. Tap on report field and select a workspace to move the expense to.
6. Navigate to workspace and open expense report.
7. Note that a "Rate not valid for this workspace" error message appears.
8. Open "Rate" field and select any valid rate.
9. Note that error and RBR are cleared.
10. Return to chat.
11. Note that after some seconds, RBR and "Rate not valid for this workspace" error message reappear.

Expected Result:

"Rate not valid for this workspace" error message should disappear after selecting a valid rate and should not reappear after some time.

Actual Result:

"Rate not valid for this workspace" error message and RBR reappear after seleting a valid rate for 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

Bug7094259_1772677983345.Not_Valid.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043666502744366749
• Upwork Job ID: 2043666502744366749
• Last Price Increase: 2026-04-13

[MelvinBot]

Proposal

What is the root cause of that problem?

Race condition between two sequential API calls: CHANGE_TRANSACTIONS_REPORT (move) and UPDATE_MONEY_REQUEST_DISTANCE_RATE (rate selection).

When a distance expense is moved from Self DM to a workspace, changeTransactionsReport (Transaction.ts:1046-1058) updates the reportID but does not update the customUnitRateID — it stays as the Self DM P2P rate (e.g. _FAKE_P2P_ID_). The optimistic violation check at ViolationsUtils.ts:421-434 correctly detects this as invalid and adds CUSTOM_UNIT_OUT_OF_POLICY.

When the user then selects a valid rate, updateMoneyRequestDistanceRate (UpdateMoneyRequest.ts:650-723) optimistically clears the violation. However, changeTransactionsReport has no successData for transaction violations (Transaction.ts:1060-1067), so the backend's Pusher response delivers its own violation calculations — computed with the original stale P2P rate — which overwrites the optimistic clear from the rate update, making the error reappear.

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

In changeTransactionsReport, when moving a distance expense to a workspace, auto-select a valid default rate for the destination workspace and update the transaction's customUnitRateID in the optimistic data. This mirrors what the backend should do and prevents the stale P2P rate from persisting.

Specifically, in Transaction.ts around the optimistic data for the move:

1. Detect when the transaction is a distance request and the destination is a paid group policy
2. Check if the current customUnitRateID is valid for the destination policy (using getDistanceRateCustomUnitRate)
3. If not valid, find the workspace's default distance rate and include the updated customUnitRateID in the optimistic transaction data and in the API params sent to the backend
4. This ensures the violation check in ViolationsUtils.getViolationsOnyxData uses the corrected rate, and the backend processes the move with the correct rate from the start — eliminating the race condition entirely

What alternative solutions did you explore? (Optional)

An alternative would be to add successData for transaction violations in changeTransactionsReport that nullifies the violations so they get re-fetched from the server after the full queue processes. However, this only masks the timing issue and doesn't fix the underlying problem that the rate stays invalid after a move. Auto-selecting a valid rate at move time is the more correct fix since it addresses the actual data inconsistency.

Investigation details

Race condition timeline:

1. CHANGE_TRANSACTIONS_REPORT sent (transaction still has P2P rate)
2. Client shows "Rate not valid" violation (correct)
3. User picks valid rate
4. UPDATE_MONEY_REQUEST_DISTANCE_RATE sent, optimistically clears violation
5. Backend response from step 1 arrives via Pusher with stale violations (still showing invalid rate) — overwrites step 4's optimistic update
6. Violation reappears
7. Eventually backend response from step 4 arrives and clears it

Key code paths:

• changeTransactionsReport violation computation: Transaction.ts:1114-1124 — uses unmodified transaction with old rate
• CUSTOM_UNIT_OUT_OF_POLICY check: ViolationsUtils.ts:421-434
• Pusher updates bypass queue and apply immediately: OnyxUpdates.ts:81-93
• Sequential queue flush: SequentialQueue.ts:356-359

Possibly related open issues:

• Chat - Rate not valid for this workspace error in SelfDM preview after rejecting WS distance expense #75353 — Rate not valid error in SelfDM preview after rejecting WS distance expense (HOLD)
• "Rate not valid for this workspace" is shown on expense preview but missing in expense thread #72337 — "Rate not valid for this workspace" shown on expense preview but missing in expense thread (HOLD)
• Distance - No rate error on confirm page when submitting expense with invalid rate from self DM #87207 — No rate error on confirm page when submitting expense with invalid rate from self DM

---

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.

[melvin-bot]

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