Tag shows empty state, Tax rate does not show all rates when creating expense from FAB

[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.89-1
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: #91580
Email or phone of affected tester (no customers): sdjsodnjiodsjsoinj1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.
• Enable Rules, Tags and Taxes in workspace settings.
• Create a tag in Tags settings.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Open FAB > Create expense > Manual.
4. Open Tag.
5. Click RHP back button.
6. Open Tax.

Expected Result:

In Step 4, workspace tags will be shown.
In Step 6, workspace taxes will be shown.

Actual Result:

In Step 4, tag empty state is shown.
In Step 6, only 0% tax rate is shown.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165792_1780003711339.3.mp4

View all open jobs on GitHub

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

[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/a5fdd6d192f36353f9977632bf1197aafbb45ceb45243a6fff8753c75889a6ec

[melvin-bot]

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

[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.

[lanitochka17]

Deploy Blocker ##92026 was identified to be related to the PR ##91580 that attempted to fix this issue.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #91580 only fixed how IOURequestStepConfirmation itself derives the workspace policy — it didn't carry that fix into the downstream Tag and Tax picker pages, which are separate routes navigated to from the confirm page.

In the FAB → Create expense → Manual flow (with newManualExpenseFlow beta), the FAB generates a brand-new optimistic reportID (FloatingActionButtonAndPopover.tsx:32) that has no corresponding REPORT_<id> entry in Onyx. The workspace chat is only known after the user picks it in the participant picker, where it gets stored on the draft transaction as participants[0].reportID.

The confirm page now resolves the correct workspace policy via reportReal ?? participantReport (IOURequestStepConfirmation.tsx:146), but when the user taps Tag or Tax the navigation reuses the original (optimistic) route.params.reportID. On the picker pages, withWritableReportOrNotFound resolves report = undefined from that ID, usePolicyForTransaction is fed report?.policyID = undefined, and the workspace tags / tax rates load as empty.

Code references

• Tag picker — only consumes report?.policyID, no participant fallback: IOURequestStepTag.tsx:54-66
• Tax picker — same pattern: IOURequestStepTaxRatePage.tsx:43-65
• Navigation forwards the unchanged reportID from the confirm page: TagFields.tsx:64-70, TaxFields.tsx:61
• withWritableReportOrNotFound resolves report from route.params.reportID only: withWritableReportOrNotFound.tsx:73
• Origin of the optimistic reportID: FloatingActionButtonAndPopover.tsx:32 → ExpenseMenuItem.tsx:34

The Tax-only-shows-0% symptom is the same mechanism: the Tax page resolves policy = undefined, falls back to the no-policy default tax rate (0%) instead of the workspace's configured tax rates.

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

Mirror the PR #91580 fallback inside both IOURequestStepTag.tsx and IOURequestStepTaxRatePage.tsx:

1. Read the participant report from Onyx using transaction?.participants?.at(0)?.reportID, the same way the confirm page now does.
2. When deriving the reportPolicyID passed to usePolicyForTransaction, fall back from report?.policyID to getIOURequestPolicyID(transaction, participantReport).

This keeps the change narrow, matches the just-shipped confirmation fix, and unblocks the deploy without touching shared HOCs or route definitions.

A follow-up sweep is recommended: any other picker step reached from the confirm page that resolves its policy via report?.policyID (Category, Distance Rate, Destination, etc.) will hit the same problem in this flow. IOURequestStepCategory.tsx:68 already uses reportReal ?? transactionReport and may be safe, but the others should be audited as part of the same fix to avoid follow-up deploy blockers.

What alternative solutions did you explore? (Optional)

• Pass policyID (or the participant's reportID) as an explicit route param on the Tag/Tax routes from TagFields/TaxFields. More invasive — requires touching ROUTES.ts, both getRoute signatures, the two step pages, and the route type definitions.
• Change withWritableReportOrNotFound to fall back to the participant report from the draft transaction. Broadest blast radius — affects every page using the HOC.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.