Fix: resolve step-page policy from the selected workspace participant by oqildev · Pull Request #101023 · Expensify/App

oqildev · 2026-09-12T12:14:35Z

Explanation of Change

The in-place "To" picker on the confirmation page rewrites the transaction participants but leaves the route on the report the flow started from — the self-DM, whose policyID is the _FAKE_ placeholder. Every step page reached from that confirmation then resolves its policy from a route report that no longer matches the expense, so getMileageRates() runs against an undefined policy and the distance Rate list renders empty. Switching back to a workspace whose rates displayed a moment earlier does not recover it, because each selection re-reads the same frozen route report.

I verified this by reading the Rate route at three points while changing the selected workspace — the reportID is identical every time:

picked workspace B → ...?action=create&iouType=track&transactionID=1&reportID=7018390717798689
picked workspace A → ...?action=create&iouType=create&transactionID=1&reportID=7018390717798689
picked workspace B → ...?action=create&iouType=create&transactionID=1&reportID=7018390717798689

This resolves the picked workspace inside usePolicyForTransaction instead, so the transaction participants — the only thing in the flow that tracks what the user actually selected — win over a route report that can no longer change. It is the same expression five call sites already pass in, so for them it is a no-op; the call sites that pass a raw report?.policyID are fixed. The helper's action === EDIT guard keeps an existing expense's own report authoritative while editing, which is a live path since the Rate page is also reachable with action=edit.

Note on scope: the first row above (iouType=track) deliberately still resolves through the moving-expenses policy. At that point the expense is still a self-DM track expense, so that behaviour is intended and unchanged.

Fixed Issues

$ #98323
PROPOSAL: #98323 (comment)

Tests

Precondition: two workspaces with distance rates enabled and clearly different rates (e.g. workspace A = $5.00/mi, workspace B = UZS 0.76/mi). Workflows → Submissions is off on both.

FAB → Track distance → Manual, enter a distance → Next.
On the confirmation page, tap "To" and select workspace B's chat.
Tap Rate. Verify the list shows workspace B's rates and is not empty.
Go back, tap "To" and select workspace A's chat.
Tap Rate. Verify the list shows workspace A's rates and is not empty.
Go back, tap "To" and select workspace B again.
Tap Rate. Verify workspace B's rates are shown again (the list does not stay empty).
Select a rate and create the expense. Verify it is created in workspace B with B's rate.

A unit test covering this was added in tests/unit/hooks/usePolicyForTransactionTest.tsx: the two bug cases fail on main and pass with this change, and three guard cases (editing an existing expense, a P2P participant, and a self-DM track expense) hold in both.

Verify that no errors appear in the JS console

Offline tests

Same as tests.

QA Steps

Same as tests.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

native.android.mp4

Android: mWeb Chrome

android.mWeb.mp4

iOS: Native

native.ios.mp4

iOS: mWeb Safari

ios.mWeb.mp4

MacOS: Chrome / Safari

web.chrome.mp4

web.safari.mp4

The in-place "To" picker on the confirmation page rewrites the transaction participants but leaves the route on the report the flow started from - the self-DM, whose policyID is the '_FAKE_' placeholder. Every step page reached from the confirmation then resolves its policy from that frozen route report, so the distance Rate list renders empty and never recovers when the workspace is switched again. Resolve the picked workspace inside usePolicyForTransaction instead, so the transaction participants - the only thing in the flow that tracks what the user selected - win over a route report that can no longer change. The five call sites that already pass this expression are unaffected; the six that pass a raw report policyID are fixed. Fixes Expensify#98323

melvin-bot · 2026-09-12T12:14:41Z

@eVoloshchak Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

eVoloshchak · 2026-09-14T19:29:53Z

Looking good!
The tests are failing, could you merge the latest main please?

…rate-selected-workspace

oqildev · 2026-09-15T10:02:56Z

@eVoloshchak Merged the latest main. The failing NavigateTests.tsx cases were coming from main - the same three tests were failing on unrelated PRs too (e.g. #101017) - and all checks are green now. Ready for another look.

eVoloshchak · 2026-09-17T14:15:53Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

eVoloshchak

Bug 1

Go to Account -> Troubleshoot -> Clear cache and restart (or perform a fresh login)
FAB → Track distance → Manual, enter a distance → Next.
Verify that self DM (you) is selected in To section
Verify the default rate is selected
Tap "To" and select a workspace with only one (default) rate
Notice the "Rate not valid for this workspace" error

Screen.Recording.2026-09-17.at.22.51.39.mov

Bug 2

Go through steps 1-7
Tap "To" and select the self DM (you)
Notice the Rate section is forever Pending

Screen.Recording.2026-09-17.at.22.56.44.mov

…rate-selected-workspace

…ves to Review of Expensify#101023 surfaced two rate problems in the in-place "To" picker. Selecting a workspace flashed "Rate not valid for this workspace" for a couple of seconds before clearing itself. Picking a participant resolves the new policy before Onyx has its custom units, so the validation effect ran with no rates to compare against and reported the selected rate as invalid; it cleared once the rates arrived. Treat an empty rate list as "not loaded yet" and leave the state alone until the effect runs again. Moving the expense back to the self DM left the Rate field reading "Pending..." and the amount blank for good, with the workspace rate error still on screen. The self-DM branch never re-resolved the rate, so the expense kept one that does not exist outside the workspace it had left, and the validation effect returned early off a workspace chat without clearing its own error. Re-resolve the rate the self DM uses, and clear the error when there is no workspace left to validate against.

codecov · 2026-09-18T06:36:56Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
...uestConfirmationList/DistanceRequestController.tsx	`82.43% <100.00%> (+1.55%)`	⬆️
src/hooks/usePolicyForTransaction.ts	`100.00% <100.00%> (ø)`
...es/iou/request/step/IOURequestStepConfirmation.tsx	`77.39% <20.00%> (-0.72%)`	⬇️
... and 132 files with indirect coverage changes

oqildev · 2026-09-18T06:51:36Z

@eVoloshchak Fixed both, thanks for the clear steps and videos.

Bug 1 was a race, not a wrong rate: picking the workspace resolves its policy before Onyx has the custom units, so validation ran with no rates to compare against and flagged the selected rate — then cleared itself once the rates arrived. An empty rate list is now treated as "not loaded yet" rather than "invalid".

Bug 2 had two halves. The self-DM branch of the participant switch never re-resolved the rate, so the expense kept one that doesn't exist outside the workspace it had left — hence Pending... and the blank amount. And the validation effect returned early once the expense was off a workspace chat, so the workspace error it set earlier was never cleared.

Three unit tests in DistanceRequestController.test.tsx cover this: the two bug cases fail without the change, and a third asserts a genuinely invalid rate is still reported, so the fix doesn't just suppress the error.

rate.mp4

pending.mp4

eVoloshchak · 2026-09-18T14:04:40Z

@oqildev, TS check is failing, could you take a look please?

The Rate type carries no unit of its own - the distance unit comes from the custom unit attributes, which already set kilometres for this mock - so tsc rejected the property and the typecheck job failed.

oqildev requested review from a team as code owners September 12, 2026 12:14

melvin-bot Bot assigned oqildev Sep 12, 2026

melvin-bot Bot requested review from eVoloshchak and heyjennahay and removed request for a team September 12, 2026 12:14

MelvinBot mentioned this pull request Sep 12, 2026

fix: Keep the sole GPS segment when a trip is stopped after one recorded point #101027

Merged

54 tasks

Merge remote-tracking branch 'upstream/main' into fix/98323-distance-…

8f54c04

…rate-selected-workspace

eVoloshchak suggested changes Sep 17, 2026

View reviewed changes

oqildev added 2 commits September 18, 2026 10:57

Merge remote-tracking branch 'upstream/main' into fix/98323-distance-…

70098b4

…rate-selected-workspace

fix: drop the unit override from the test rate mock

8e00c6b

The Rate type carries no unit of its own - the distance unit comes from the custom unit attributes, which already set kilometres for this mock - so tsc rejected the property and the typecheck job failed.

Navigation Menu

Fix: resolve step-page policy from the selected workspace participant - #101023

Fix: resolve step-page policy from the selected workspace participant#101023
oqildev wants to merge 5 commits into
Expensify:mainfrom
oqildev:fix/98323-distance-rate-selected-workspace

oqildev commented Sep 12, 2026 •

edited

Loading

Uh oh!

melvin-bot Bot commented Sep 12, 2026

Uh oh!

eVoloshchak commented Sep 14, 2026 •

edited

Loading

Uh oh!

oqildev commented Sep 15, 2026

Uh oh!

eVoloshchak commented Sep 17, 2026 •

edited

Loading

Uh oh!

eVoloshchak left a comment

Uh oh!

codecov Bot commented Sep 18, 2026 •

edited by github-actions Bot

Loading

Uh oh!

oqildev commented Sep 18, 2026

Uh oh!

eVoloshchak commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

oqildev commented Sep 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot Bot commented Sep 12, 2026

Uh oh!

eVoloshchak commented Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oqildev commented Sep 15, 2026

Uh oh!

eVoloshchak commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

eVoloshchak left a comment

Choose a reason for hiding this comment

Uh oh!

codecov Bot commented Sep 18, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

oqildev commented Sep 18, 2026

Uh oh!

eVoloshchak commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

oqildev commented Sep 12, 2026 •

edited

Loading

eVoloshchak commented Sep 14, 2026 •

edited

Loading

eVoloshchak commented Sep 17, 2026 •

edited

Loading

codecov Bot commented Sep 18, 2026 •

edited by github-actions Bot

Loading