[Due for payment 2026-06-17] Expense - Category list loads infinitely when creating expense form 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.4.0-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: #92059
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@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.

1. Go to staging.new.expensify.com
2. Open FAB > Create expense > Manual.
3. Open Category.

Expected Result:

Category list will open.

Actual Result:

Category list loads infinitely when creating expense form FAB.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172896_1780684218912.13.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @mallenexpensify

[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/83af1894780091912dc8e4c0b5005f37d78fe6db8a91ae9bb185a55a8fb6fa07

[melvin-bot]

@JS00001 recently merged #92059, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @mjasikowski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

Proposal

What is the root cause of that problem?

In the newManualExpenseFlow beta, the Manual tab renders the confirmation step directly (with the Category field) using a freshly generated optimistic reportID that has no real report behind it (IOURequestStartPage.tsx:214-238). Tapping Category navigates to IOURequestStepCategory with that fake reportID.

There, the policy can't be resolved, so the spinner never stops:

• policyID comes from getIOURequestPolicyID, which only reads a participant flagged isSender (invoice-only) or report?.policyID. The default expense-chat participant carries its policyID under isPolicyExpenseChat, not isSender, and the report doesn't exist → policyID is undefined.
• With no policyID, fetchData early-returns and never calls getPolicyCategories (which also no-ops on a falsy policyID).
• policyCategories therefore stays undefined, so isLoading = !isOffline && policyCategories === undefined is permanently true → infinite spinner.

The old flow didn't hit this because the user went Amount → participant selection first, which wrote a real chat reportID (with a real policyID) into the URL before Category ever rendered.

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

Two changes — the first is the real fix, the second is a cheap safety net:

1. Resolve the policy from the expense-chat participant. Teach getIOURequestPolicyID to also fall back to a participant carrying a policyID (e.g. transaction.participants.find(p => p.isPolicyExpenseChat)?.policyID) when there's no isSender participant and no report.policyID. This restores a valid policyID so fetchData fires and categories load. (Verify the participant seeded by useDefaultParticipants actually carries the policyID.)

2. Guard the spinner. In IOURequestStepCategory, when policyID is falsy and we're online, show the empty state / a "select a workspace" CTA instead of isLoading=true, so a missing policy can never produce an indefinite spinner again.

If product prefers, an alternative to (2) is to not let users open Category until a workspace is resolved — have CategoryField route to the workspace picker when !policy, mirroring its existing shouldSelectPolicy branch.

What alternative solutions did you explore? (Optional)

Only patching isLoading to treat missing policyID as "not loading" was rejected: it swaps the spinner for a misleading empty "no categories" state for users who do have a workspace and expected to pick a category. The policy must actually be resolved (fix 1).

Investigation details & evidence chain

Repro path (beta on): global FAB generates an optimistic reportID (FloatingActionButtonAndPopover.tsx:32) → ExpenseMenuItem calls startMoneyRequest(CREATE, reportID, …) → IOURequestStartPage renders IOURequestStepConfirmation for the Manual tab → tap Category navigates to MONEY_REQUEST_STEP_CATEGORY with the fake reportID → IOURequestStepCategory resolves policyID = undefined (lines 68-75) → spinner never resolves.

The Category field is only shown when isPolicyExpenseChat is true, i.e. the user does have a workspace context — yet getIOURequestPolicyID ignores that participant's policyID. So the bug reproduces in exactly the scenario where the user expected categories.

Confidence: High — the undefined chain is explicit and linear at every step. The fix lives entirely in Expensify/App.

---

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

[godzillaxbox19982014-lgtm]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Expense - Category list loads infinitely when creating expense form FAB

What is the root cause of that problem?

I traced this to the path that handles expense report, FAB, newManualExpenseFlow:

• src/pages/workspace/categories/DynamicExpenseLimitTypeSelectorPage.tsx:35 (currentExpenseLimitType): const currentExpenseLimitType = formDraft?.expenseLimitType ?? policyCategories?.[categoryName]?.expenseLimitType ?? CONST.POLICY.EXPENSE_LIMIT_TYPES.EXPENSE;
• src/pages/workspace/categories/DynamicCategoryRequireReceiptsOverPage.tsx:57 (convertToDisplayString): convertToDisplayString(policy.maxExpenseAmountNoReceipt, policy?.outputCurrency ?? CONST.CURRENCY.USD),
• src/pages/workspace/categories/DynamicCategoryRequireItemizedReceiptsOverPage.tsx:57 (convertToDisplayString): convertToDisplayString(policy.maxExpenseAmountNoItemizedReceipt, policy?.outputCurrency ?? CONST.CURRENCY.USD),
• The local evidence matches this recurring failure shape: shared workspace list builds options without the same eligibility filter as another workspace surface. Here, src/pages/workspace/categories/DynamicExpenseLimitTypeSelectorPage.tsx:35 and src/pages/workspace/categories/DynamicCategoryRequireReceiptsOverPage.tsx:57 do not agree on the same expense report, FAB, newManualExpenseFlow value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/workspace/categories/DynamicExpenseLimitTypeSelectorPage.tsx:35 to derive expense report, FAB, newManualExpenseFlow from the workspace setup and policy state that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/categories/DynamicCategoryRequireReceiptsOverPage.tsx:57; that follows the safer family move to move the rule into the shared selector/helper, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Workspace, Policy, Categories, Tags, Rules surface and avoid changing account/admin permission surfaces, policy owner/current-user exceptions.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/Policy*.ts for the exact issue flow: Expense - Category list loads infinitely when creating expense form FAB.
2. Cover the counter-case near src/pages/workspace/categories/DynamicExpenseLimitTypeSelectorPage.tsx:35 so valid existing expense report, FAB, newManualExpenseFlow behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep expense report, FAB, newManualExpenseFlow consistent at the first read/write boundary shown above.