[Due for payment 2026-09-10] Invoice - "1 reply" on invoice preview opens report in central pane instead of RHP

[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: 9.4.65-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: #99165
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@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:

• Enable Invoice.

1. Go to staging.new.expensify.com
2. Open FAB > Send invoice.
3. Send an invoice to any user.
4. Open invoice report.
5. Send a message.
6. Close the invoice report.
7. Click 1 reply.

Expected Result:

"1 reply" on invoice preview will open report RHP.

Actual Result:

"1 reply" on invoice preview opens report in central pane instead of RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @sobitneupane

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

[melvin-bot]

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

[melvin-bot]

@neil-marcellini @dylanexpensify @sobitneupane you have been assigned to this deploy blocker because you reviewed the offending PR: #99165

[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: #99165 - "Open money-request child reports in the wide RHP from X Replies" by @MelvinBot (High confidence)
Related Issues: #98142 (the issue #99165 was fixing)

Recommendation: ROLL FORWARD

PR #99165 gated the new "X Replies → wide RHP" routing on isMoneyRequestReport(), which is IOU || Expense and therefore excludes invoice reports, so invoices fall through to the central-pane route. A revert would not fix the reported symptom (invoices open in the central pane on production too) and would reintroduce #98142, whereas the fix is a one-line guard change.

Suggested fix in navigateToAndOpenChildReport:

-    const isMoneyRequest = isMoneyRequestReport(report);
+    const isMoneyRequest = isMoneyRequestReport(report) || isInvoiceReport(report);

This matches the pairing the codebase already uses in shouldReportAlignToTop (isMoneyRequestReport(report) || isInvoiceReport(report)).

Assigned: @sobitneupane, @neil-marcellini, @dylanexpensify (approving reviewers of #99165) — already assigned. The PR author is a bot, so there is no human author to add.
Labels: No changes. DeployBlockerCash is kept (an App PR is responsible and the fix is in Expensify/App). DeployBlocker was not present, so nothing was removed. No backend change is involved.

📋 Detailed Analysis

Evidence

#99165 is the only PR in this release that touches this code path. The "1 reply" link renders ReportActionItemThread, whose onPress calls navigateToAndOpenChildReport. That function was last modified on 2026-08-31 by commit d178dd2f (the #99165 merge), hours before this blocker was filed. I checked every other PR on the deploy checklist; none of them touch invoice previews, navigateToAndOpenChildReport, or report/RHP route mapping.

Why the RHP is the correct expectation. Any REPORT_PREVIEW action — including an invoice preview — renders MoneyRequestReportPreview via ActionContentRouter, and openReportFromPreview navigates to EXPENSE_REPORT_RHP on wide layouts with no report-type guard at all. So tapping the invoice preview card already opens the invoice report in the wide RHP, and that file has not changed since 2026-07-28 (it is production behavior). Tapping "1 reply" on the very same card now lands somewhere else.

Production vs staging. One nuance worth flagging for the deploy decision: the invoice branch is byte-for-byte what production does — before #99165, every child report (IOU, expense, invoice) went to REPORT_WITH_ID. So this is strictly an incomplete rollout of a new feature rather than a regression: #99165 moved IOU/expense to the RHP and left invoices behind, which is what makes the inconsistency visible now. That is also precisely why reverting is the wrong lever — a revert restores the old uniform central-pane behavior but still leaves the preview card (RHP) and its "1 reply" link (central pane) disagreeing.

Verification

Affected files, confirmed against the tested build 9.4.65-0 (f6a4920080351a88529deff07d47ee7a4aca8dbc):

File	Role	Touched by #99165?
src/libs/actions/Report/index.ts#L2814-L2841	The buggy routing branch	✅ Yes
src/libs/ReportUtils.ts#L2807-L2810	isMoneyRequestReport — the guard that excludes invoices	❌ No (pre-existing helper)
src/pages/inbox/report/ReportActionItemThread.tsx#L72-L76	The "1 reply" press handler	❌ No (unchanged caller)

gh pr view 99165 --json files lists src/libs/actions/Report/index.ts, confirming the PR modifies the exact file and function that decides this route.

Root Cause

navigateToAndOpenChildReport computes a single guard and branches on it:

const isMoneyRequest = isMoneyRequestReport(report);
...
if (!isMoneyRequest) {
    Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID, undefined, undefined, backTo));
    return;
}

isMoneyRequestReport is defined as:

function isMoneyRequestReport(reportOrID, reports?) {
    const report = ...;
    return isIOUReport(report) || isExpenseReport(report);
}

and isIOUReport/isExpenseReport are strict equality checks on report.type against CONST.REPORT.TYPE.IOU and CONST.REPORT.TYPE.EXPENSE. An invoice report has type === CONST.REPORT.TYPE.INVOICE, so isMoneyRequestReport() returns false, the !isMoneyRequest early return fires, and the invoice opens via REPORT_WITH_ID in the central pane. The shouldScrollToLatest param is also skipped, so even the scroll-to-latest half of the feature is missing for invoices.

The PR description states it mirrors the routing in Link.ts and ParentNavigationSubtitle.tsx — and it does, faithfully. Those two call sites have the same invoice omission (Link.ts#L371 and ParentNavigationSubtitle.tsx#L248), so an invoice report reached via a report link or the parent-report subtitle should also be checked and is worth a follow-up issue.

---

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-19 Include invoice reports when gating wide-RHP report routing
• Condition: When a navigation decision picks ROUTES.EXPENSE_REPORT_RHP or ROUTES.SEARCH_MONEY_REQUEST_REPORT behind an isMoneyRequestReport(...) guard, the guard must also admit invoice reports (|| isInvoiceReport(report)), because invoice reports render in that same wide RHP. Flag any such guard where isInvoiceReport is absent.
• Why: isMoneyRequestReport() is only IOU || Expense, but the wide RHP and MoneyRequestReportView also serve type === INVOICE. Using it as the RHP gate silently routes invoices to the narrow central-pane route, splitting behavior between an invoice preview card and its own "1 reply" link — this deploy blocker. The codebase already models the correct pairing in shouldReportAlignToTop.
• Search pattern: isMoneyRequestReport\( appearing within ~10 lines of EXPENSE_REPORT_RHP|SEARCH_MONEY_REQUEST_REPORT in the same function, with no isInvoiceReport in that block. Currently matches 3 call sites: src/libs/actions/Report/index.ts, src/libs/actions/Link.ts, src/components/ParentNavigationSubtitle.tsx.
• Offending code (❌): src/libs/actions/Report/index.ts#L2819-L2833
• Fix (✅): the one-line guard change above, matching shouldReportAlignToTop

The full rule file, with the ❌/✅ code inline in Expensify/App's coding-standards format, would go in Expensify/App itself (.claude/skills/coding-standards/rules/). If it's worth adding, a maintainer can open it there as a draft PR.

[MelvinBot]

TL;DR of my full investigation above: roll forward, don't revert.

#99165 gated the new "X replies → wide RHP" routing on isMoneyRequestReport(), which is IOU || Expense only. Invoice reports (type === INVOICE) fail the guard and fall through to the central-pane route in navigateToAndOpenChildReport.

-    const isMoneyRequest = isMoneyRequestReport(report);
+    const isMoneyRequest = isMoneyRequestReport(report) || isInvoiceReport(report);

isInvoiceReport is already imported in that file (line 164), so the change compiles as-is, and it matches the pairing already used in shouldReportAlignToTop.

A revert would not fix the symptom — invoices open in the central pane on production too — and would reintroduce #98142.

---

view run