Repository navigation
[Due for payment 2026-09-03] Spend - Navigation arrows disappear after opening invoice sent from OD #99636
Description
Activity
- addedDeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deploymentBugSomething is broken. Auto assigns a BugZero manager.Something is broken. Auto assigns a BugZero manager.
on Aug 27, 2026 While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f4f79b3656d4e21efeee24fbc54c43e7df3cc512306a7762573f4a379929198dYou have been assigned to this deploy blocker because you recently merged this PR: #98611
@JS00001 @ShridharGoel you have been assigned to this deploy blocker because you reviewed the offending PR: #98611
@thelullabyy you have been assigned to this deploy blocker because you authored the offending PR: #98611
💬 A slack conversation has been started in #expensify-open-source
github-actions commented
on Aug 27, 2026 on Aug 27, 2026 – with GitHub ActionsContributorMore 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:
- Identify the pull request that introduced this issue and revert it.
- Find someone who can quickly fix the issue.
- Fix the issue yourself.
🔍 Investigation Summary
Classification: Frontend bug (fix belongs in
Expensify/App)
Causing PR: #98611 - "Standardize Expense Report and Expense header with predictable button placement and carousel counter" by @thelullabyy (High confidence PR / Medium-High confidence on exact branch)
Related Issues: Original feature issue #90366 (linked in the PR)Recommendation: ROLL FORWARD (targeted fix)
#98611 is a large, foundational header-standardization PR that also introduced the entire Search → RHP prev/next carousel ("Search invoice/report navigation"). The break only affects multi-expense invoices originating from OldDot, a narrow edge case, so a targeted fix is safer than reverting the whole standardization + carousel + test suite. Revert is the fallback if a fix can't land quickly.
Assigned: @thelullabyy (PR author), @ShridharGoel and @JS00001 (approving reviewers) — already auto-assigned by melvin-bot, no change needed.
Labels: No change.DeployBlockerCashis correct and kept (App-side fix required; feature is staging-only / not in production).DeployBlocker(web) is not present and none was removed.📋 Detailed Analysis
Evidence
- The bug is a new feature not in production (Search invoice navigation), reproducible only on staging
9.4.62-1. - Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 is on the current
StagingDeployCashchecklist (Deploy Checklist: New Expensify 2026-08-26 #99596) and merged2026-08-26, aligning with the staging build where the bug first appears. - Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 is the PR that introduced the Search-seeded transaction carousel and rewrote every file in the arrow-visibility path: it added
carouselSiblingTransactionIDsand thesetActiveTransactionIDs(...)seeding insrc/components/Search/index.tsxL563-L590 and L764-L775, rewroteMoneyRequestReportTransactionsNavigation.tsx(233+/148-), and added the anchor-resolution + branch logic inMoneyReportHeader.tsx. - The repro difference is exactly single-expense (ND: "two invoices", one expense each) vs multi-expense (OD: "an invoice with two expenses"), which maps directly onto the
singleTransactionIDbranch introduced by this PR.
Verification
Affected files (all touched by #98611):
src/components/MoneyReportHeader.tsxL104-L107 — resolvescarouselAnchorTransactionIDandshouldShowTransactionNavigation.src/components/MoneyReportHeader.tsxL178-L189 — chooses between transaction-nav and report-nav.src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsxL52 and L268-L294 — report-level arrows are gated totype === EXPENSE_REPORTonly.
Root Cause
When Search Type = Invoices, invoices get prev/next arrows from one of two mutually exclusive paths in
MoneyReportHeader:- Transaction carousel (L178-L189) — shown only when
shouldShowTransactionNavigationis true, i.e. acarouselAnchorTransactionIDresolves and is present in the seededactiveTransactionIDs. The anchor is resolved as:
carouselAnchorTransactionID = singleTransactionID ?? threadTransactionID ?? multiTxAnchorTransactionID(L104-L107). - Report carousel — the fallback, but
MoneyRequestReportNavigationonly ever mounts fortype === EXPENSE_REPORT, so for an INVOICE-type search it returnsnulland shows nothing.
For a single-expense ND invoice, the landed report has exactly one transaction, so
singleTransactionIDresolves and is inactiveTransactionIDs→ transaction carousel shows the arrows. ✅For a multi-expense OD invoice, the landed report has two transactions, so:
singleTransactionIDisundefined(2 transactions),threadTransactionIDisundefined(the invoice report's parent action is not a money-request action),multiTxAnchorTransactionIDfails to resolve because the route/anchorTransactionIDfor the multi-transaction invoice report is not a valid entry in the seededactiveTransactionIDs(L104-L105).
With no anchor,
shouldShowTransactionNavigationis false, and the fallback report navigation is disabled for INVOICE searches → all arrows disappear. OD-origination matters because OD invoices are the ones carrying multiple expenses (and whose IOU report-actions/threads aren't reliably hydrated in ND for anchor resolution).Suggested fix direction
Either (a) extend the report-navigation guard to also handle
type === INVOICEso multi-expense invoices fall back to report-level arrows, or (b) resolve a validcarouselAnchorTransactionIDfor multi-transaction invoice reports opened from Search (e.g. derive the anchor from the report's own transactions when the route anchor is absent, and ensure invoice siblings are seeded intoactiveTransactionIDs).- The bug is a new feature not in production (Search invoice navigation), reproducible only on staging
Chrome / v9.4.62-4
No arrows on invoice RHPbandicam.2026-08-27.21-06-37-427.mp4
- removedDeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deploymentHourlyKSv2KSv2
on Aug 27, 2026 - changed the title
[-]Spend - Navigation arrows disappear after opening invoice sent from OD[/-][+][Due for payment 2026-09-03] Spend - Navigation arrows disappear after opening invoice sent from OD[/+]on Aug 27, 2026 The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.62-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-09-03. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
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.62-1
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: #98611
Email or phone of affected tester (no customers): sjdonijsdoisdjnio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search
Action Performed:
Precondition:
Expected Result:
Navigation arrows will not disappear after opening invoice sent from OD.
Actual Result:
Navigation arrows disappear after opening invoice sent from OD.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7243927_1787810216041.11.mp4
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @thelullabyy