[Due for payment 2026-08-25] Expense-The manual tab does not open when clicked

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.52-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: #97264
Email or phone of affected tester (no customers): applausetester+ag300726@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/ Chrome
App Component: Money Requests

Action Performed:

Precondition: Have at least one workspace with Submissions disabled.

1. Go to staging.new.expensify.com
2. Login with an Expensifail account
3. Open FAB > Create expense > Manual
4. Go to Scan tab
5. Upload a receipt
6. Select self DM
7. Click the RHP back button twice
8. Click on the Manual tab

Expected Result:

The manual tab opens.

Actual Result:

The manual tab does not open. Only opens when clicked for the second time.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7230600_1786406482778.manual_tab.mp4

View all open jobs on GitHub

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

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/a9e8fbbecf7ce42a2536cbd2ca779718a31b194690c3c57023a8e71f707ea697

[melvin-bot]

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

[melvin-bot]

@puneetlath @ikevin127 you have been assigned to this deploy blocker because you reviewed the offending PR: #97264

[melvin-bot]

@thelullabyy you have been assigned to this deploy blocker because you authored the offending PR: #97264

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #97264 - "fix (batch 2): isNewManualExpenseFlowEnabled beta flag regressions" by @thelullabyy (High confidence)
Related Issues: This PR fixed #93854, #96558, #96632, #96653, #96559, #96577 — a full revert would reintroduce those.

Recommendation: ROLL FORWARD

The regression lives in the same newManualExpenseFlow tab/reset machinery that PR #97264 reworked, but a full revert would re-open the six beta regressions this PR fixed. A targeted fix to the latched staleness check is safer than reverting the whole batch.

Assigned: @thelullabyy (PR author), @ikevin127 and @puneetlath (approving reviewers) — already auto-assigned to this issue.
Labels: No change. DeployBlockerCash is kept (an App PR caused this, so the App deploy is correctly blocked). No DeployBlocker (web) label is present, so nothing to remove.

📋 Detailed Analysis

Evidence

• PR fix (batch 2): isNewManualExpenseFlowEnabled beta flag regressions #97264 is item Figure out how to do tooltip for comment timestamps #31 on the current StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-08-10 #98179, release 9.4.52-0) and is still unchecked — it is on staging in exactly the version where this blocker was reported.
• The bug is staging-only, not reproducible on production, so it was introduced by a PR in this staging deploy.
• The reproduction preconditions (workspace with Submissions disabled, self DM, Manual/Scan tab switching) exercise the new manual expense flow beta — the precise feature area this PR targets ("isNewManualExpenseFlowEnabled beta flag regressions").
• The PR modifies the exact tab/reset machinery involved: OnyxTabNavigator.tsx, OnyxTabNavigatorConfig, IOURequestStartPage.tsx, useResetIOUType.ts, useDefaultParticipants.ts.
• Reviewer @ikevin127 flagged a sibling tab-switch regression during review (recipient cleared on Manual → Scan → Manual). The current bug is another member of that same tab-switch-back class.

Verification

• Affected file: src/pages/iou/request/IOURequestStartPage.tsx.
• The net diff of fix (batch 2): isNewManualExpenseFlowEnabled beta flag regressions #97264 replaces the per-render staleness check
  const isStaleTransactionDraft = !!transaction?.reportID && transaction.reportID !== reportID;
  with a latched version (current lines 148–152):

  const [latchedDraftStaleness, setLatchedDraftStaleness] = useState<{reportID: string; isStale: boolean}>();
  if (!isLoadingTransaction && latchedDraftStaleness?.reportID !== reportID) {
      setLatchedDraftStaleness({reportID, isStale: !!transaction?.reportID && transaction.reportID !== reportID});
  }
  const isStaleTransactionDraft = latchedDraftStaleness?.isStale ?? false;

• isStaleTransactionDraft feeds transactionRequestType (lines 154–167), which drives both the rendered tab content (manualTabContent, lines 227–262) and the tab reset (useResetIOUType, src/hooks/useResetIOUType.ts:105–159).

Root Cause

The latch only recomputes when the URL reportID changes (latchedDraftStaleness?.reportID !== reportID). It ignores changes to the draft's transaction.reportID. In the repro, selecting the self DM inside the Scan sub-flow sets transaction.reportID to the self-DM report while the URL reportID (global create) stays the same, so the latch is never refreshed and isStaleTransactionDraft stays false.

Because it stays false, transactionRequestType takes the first branch and returns the stale scan draft's type:

if (transaction?.iouRequestType && !isStaleTransactionDraft) {
    return transaction.iouRequestType; // SCAN, even though Manual was just clicked
}

So on the first click of the Manual tab, the tab bar highlights Manual but transactionRequestType is still SCAN, and manualTabContent renders the manualTabPendingReset loader instead of the confirmation. The persisted tab change fires resetIOUTypeIfChanged (useResetIOUType.ts) asynchronously to rebuild the draft as manual; only after that Onyx round-trip lands does a second click resolve transactionRequestType to MANUAL and render the Manual tab — hence "opens only on the second click."

The pre-#97264 code computed staleness every render, so the self-DM-driven transaction.reportID divergence would have marked the draft stale immediately and let transactionRequestType fall through to the freshly-selected tab. The latch (added to stop an unrelated true → false → seeded flip that @ikevin127 flagged) over-corrected and suppressed this legitimate staleness signal.

Suggested fix direction (roll forward): refresh the latch when the draft's transaction.reportID diverges from the URL reportID mid-flow (not only when the URL reportID changes), or have transactionRequestType prefer a just-selected valid selectedTab over a stale draft type — while re-checking that this does not reintroduce the #96558 participant-picker flash the latch was guarding against.