[Due for payment 2026-05-13] Expense - Category RHP remains open after creating workspace and adding a new category

[jponikarchuk]

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.67-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: #86177
Email or phone of affected tester (no customers): sdjoisdjoijdosjni@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / 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. Create a manual expense.
4. Open the expense.
5. Click Category.
6. Click Upgrade > Got it, thanks.
7. Click + button on the top right.
8. Enter name and click Save.

Expected Result:

Category RHP will close after creating workspace and adding a new category.

Actual Result:

Category RHP remains open after creating workspace and adding a new category.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ahmedGaber93

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #86177 - "Feat: add a new category within the category list" by @daledah (High confidence)
Related Issues: #85681 (the original issue this PR fixed)

Recommendation: REVERT

PR #86177 introduced a new IOURequestStepCategoryCreate screen and the logic for creating a category in-situ from the IOU category picker. The navigation logic in the createCategory callback has a bug that leaves the Category RHP open after saving.

Assigned: @daledah (PR author), @ahmedGaber93 (approving reviewer), @amyevans (approving reviewer)
Labels: DeployBlockerCash kept (Frontend App bug). No label changes made.

Detailed Analysis

Evidence

• The melvin-bot comment on the deploy blocker issue explicitly identifies PR Feat: add a new category within the category list #86177 as the causing PR.
• PR Feat: add a new category within the category list #86177 is in the StagingDeployCash checklist for release 9.3.67-0, which matches the version in the bug report.
• The bug is only reproducible on staging and is classified as a new feature ("N/A - new feature, doesn't exist in prod"), consistent with PR Feat: add a new category within the category list #86177 being the first introduction of this functionality.
• The reproduction steps exactly match what PR Feat: add a new category within the category list #86177 implemented: clicking "+" on the category picker to create a new category in-situ after upgrading to a workspace.

Verification

• The affected files are src/pages/iou/request/step/IOURequestStepCategoryCreate.tsx and src/pages/iou/request/step/IOURequestStepCategory.tsx, both introduced/modified by PR Feat: add a new category within the category list #86177.
• PR Feat: add a new category within the category list #86177 creates the new IOURequestStepCategoryCreate page and adds the "+" menu item to IOURequestStepCategory that triggers navigation to it.

Root Cause

In IOURequestStepCategoryCreate.tsx, the createCategory callback (line ~149-153) handles post-save navigation:

if (isEditing) {
  Navigation.goBack(backTo);
} else {
  Navigation.goBack(
    ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(
      action,
      iouType,
      transactionID,
      reportID,
    ),
  );
}

The scenario in the bug report is the non-editing path (creating a manual expense from the self DM, not editing an existing one). After the Upgrade flow (UPGRADE_PATHS.CATEGORIES), the navigation stack contains the Category RHP screen. When createCategory is called and invokes Navigation.goBack(ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(...)), this attempts to go back to the confirmation route, but the Category RHP screen (IOURequestStepCategory) sitting below the create screen in the navigation stack is never dismissed — it remains rendered and visible to the user. The goBack with a target only pops to the nearest matching route in the stack, leaving the category RHP behind instead of dismissing both the create screen and the category picker screen together.

The fix would need to either: (a) navigate past the Category screen by dismissing multiple screens, or (b) use Navigation.dismissModal or a similar approach that properly collapses the entire RHP stack back to the confirmation step.