[HOLD App 100555] Expense-Rate violation disappears after moving expense to another report

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: V9.4.52-2
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/folder/13176670/test-cases/41237109
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

Pre-condition Have 2 Workspace

1. Launch app
2. Open default workspace chat
3. Create a distance manual expense
4. Open the expense
5. Tap more - change workspace
6. Note distance row shows Rate not valid for this workspace
7. Create another report ( not default workspace)
8. Open the expense - More - move report - select report created in step 6
9. Note Rate not valid for this workspace violation is not shown

Expected Result:

The “Rate not valid for this workspace” violation should remain displayed after moving the expense to another report within the same workspace, since the workspace and distance rate have not changed.

Actual Result:

The “Rate not valid for this workspace” violation disappears after moving the expense to another report within the same workspace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7231099_1786465181507.Screenrecorder-2026-08-11-21-39-33-859.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7231099

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022087235223820572902
• Upwork Job ID: 2087235223820572902
• Last Price Increase: 2026-08-11

Issue Owner

Current Issue Owner: @neil-marcellini

[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/041ded28aadd370cfd593e17b4eea78d6b956131f0535f50080cc59bb42e53e1

[MelvinBot]

Proposal

Root Cause: When you move a distance expense to another report, changeTransactionsReport runs an "auto-select a valid default rate" block that fires for any group-policy destination whenever the expense's current rate is invalid/disabled — with no check that the destination is a different workspace (Transaction.ts:1218-1224). A "Rate not valid for this workspace" expense has an invalid rate by definition, so moving it to another report on the same workspace swaps in that workspace's default mileage rate, recalculates amount/merchant/currency, and sends the new rate to the backend. The violation recompute right after then sees a now-valid rate and drops customUnitOutOfPolicy (ViolationsUtils.ts:665-667) — so the violation disappears even though nothing about the workspace or rate should have changed.

This also explains why the "change workspace" path behaves correctly: changeReportPolicy does not auto-swap the rate, so the violation persists there as expected.

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

Guard the auto-rate-selection block in getChangeTransactionsReportOnyxData so it only runs when the destination report is on a different policy than the transaction's current/source report. When moving within the same workspace, skip the rate swap entirely — leave the invalid rate (and its customUnitOutOfPolicy violation) untouched. The subsequent violation recompute will then correctly preserve the "Rate not valid for this workspace" violation.

Investigation details & evidence

Violation: customUnitOutOfPolicy (CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY), rendered from en.ts:9832 → 'Rate not valid for this workspace'. It is computed client-side/optimistically in ViolationsUtils.getViolationsOnyxData: pushed when the transaction's customUnitRateID doesn't resolve to an enabled rate in the policy, and reject()-ed (cleared) when it does.

Data flow on the buggy move:

1. Distance expense already carries customUnitOutOfPolicy (rate invalid for its workspace).
2. Move to a different report → changeTransactionsReport → getChangeTransactionsReportOnyxData.
3. Transaction.ts:1221-1224: isGroupPolicy(policy) && isDistanceRequest(transaction) is true and the current rate is invalid → enters the block. There is no oldReport.policyID !== policy.id check here.
4. It picks getDefaultMileageRate(policy), recalculates amount/merchant/currency, and records transactionIDToUpdatedCustomUnitRateID — which is also sent to the backend, so the change persists on success (not just optimistically).
5. Transaction.ts:1319-1341 recomputes violations with the now-valid rate → customUnitOutOfPolicy is rejected → violation disappears.

Alternative explanation considered: that the backend independently drops the violation on move. Ruled out as the trigger — the client both swaps the rate and tells the backend to do so, so the disappearance originates in App's optimistic path. (Backend behavior wasn't inspected but the client change is sufficient to explain the symptom.)

Confidence: High — root cause pinned to exact code, both the buggy path and the correct "change workspace" contrast path verified.

Possibly related issues (same "invalid rate" feature cluster)

• [Exploratory] Expense-Invalid rate violation missing offline and duplicate expense causes unexpected error #98333 — Invalid rate violation missing offline / duplicate expense error
• [Exploratory] Expense-Split distance expense with rate not valid violation shows unexpected error. #98339 — Split distance expense with rate-not-valid violation shows unexpected error
• [Due for payment 2026-09-07][$250] Expense Report- "Rate not valid for this workspace" error msg not appears #96319 — "Rate not valid for this workspace" error msg not appearing

---

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

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@abdulrahuman5196 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@abdulrahuman5196 Still overdue 6 days?! Let's take care of this!

[melvin-bot]

@abdulrahuman5196 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[abdulrahuman5196]

Checking now