Repository navigation
[Due for payment 2026-09-03] Spend - Arrow carousel disappears after duplicating expense. #99630
Description
Activity
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/ca6a877480a279aafbe5cda9b0852c834a8a61c0a1abc962f8cfaea23ec1eceeYou 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
👋 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
Causing PR: #98611 - "Spend header / expense carousel rework (fixes #90366)" by @thelullabyy (High confidence)
Related Issues: #90366 (the issue #98611 was implementing)Recommendation: REVERT
PR #98611 rewrote the exact code that powers the arrow carousel (seeding, clearing, and rendering), it is staging-only, and the regression does not reproduce on production — reverting cleanly restores known-good carousel behavior. A targeted roll-forward fix is viable if preferred (see Root Cause), but revert is the safe default for a deploy blocker.
Assigned: @thelullabyy (PR author), @ShridharGoel and @JS00001 (approving reviewers) from the causing PR
Labels: No changes.DeployBlockerCashis kept (App/frontend deploy is blocked).DeployBlockerwas not present. Not reproducible on production, so no blocker label may be removed.📋 Detailed Analysis
Evidence
- The issue is staging-only (Reproducible in production: No). PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 merged
2026-08-26and is listed in the currentStagingDeployCashchecklist (Deploy Checklist: New Expensify 2026-08-26 #99596); the reporter's version9.4.62-1and report date2026-08-27line up with it. - The BrowserStack regression link recorded on the issue points directly at PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611, and Melvin auto-assigned the author/reviewers of that PR.
- The bug is squarely in the area Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 rewrote. The PR touches every file that drives the "arrow carousel":
src/components/MoneyRequestReportView/MoneyRequestReportTransactionsNavigation.tsx,src/libs/actions/TransactionThreadNavigation.ts,src/hooks/useNavigateToTransactionThread.ts,src/components/Search/index.tsx,src/components/Search/SearchList/ListItem/TransactionGroupListExpanded.tsx, andsrc/components/MoneyRequestHeader.tsx.
Verification
The carousel is
MoneyRequestReportTransactionsNavigation. It renders only when the seeded sibling list has 2+ entries:MoneyRequestReportTransactionsNavigation.tsxreads the list from Onyx and returnsnullwhen it has fewer than 2 IDs — L82 / L210-212.- The header mounts the carousel in the RHP expense view —
MoneyRequestHeader.tsxL192-198.
So the carousel disappears when the seeded Onyx key
TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDSdrops below 2 entries.Root Cause
Before #98611, once the carousel's sibling list was seeded it was only cleared on unmount (guarded by a preserving-screen check). #98611 made that shared list continuously reactive to search data by adding a new effect in
Search/index.tsxthat re-writes it whenever the underlying search results change, gated by a new snapshot-hash check:- New re-seed effect:
src/components/Search/index.tsx~L760-772 — callssetActiveTransactionIDs(carouselSiblingTransactionIDs, hash)onfilteredDatachanges. carouselSiblingTransactionIDsis derived fromfilteredDataand drops any deleted / pending-delete transactions:src/components/Search/index.tsx~L563-572.- The gate
shouldWriteActiveTransactionIDsForSearchinsrc/libs/actions/TransactionThreadNavigation.tsL79-95 permits overwriting the already-seeded list once the active snapshot hash matches the current search hash and the ID sets differ.
"Duplicate expense" (
useExpenseActions.ts→duplicateExpenseTransaction→duplicateExpenseTransactioninlibs/actions/IOU/Duplicate.ts) mutates the underlying search data: it creates a new optimistic expense and causes the original transaction to gain a potential-duplicate violation (which also flipsMoneyRequestHeader'sstatusBarProps/isDuplicateat L96 / L125-127). The still-mounted Spend search recomputescarouselSiblingTransactionIDsand the re-seed effect fires while the RHP expense view is open. Because the effect now owns the shared list, the recomputed/optimistically-churningfilteredDataoverwrites the previously-seeded siblings with a set that no longer contains 2+ entries for the current expense's context, soMoneyRequestReportTransactionsNavigationrendersnulland the carousel disappears — exactly the reported symptom.Because the offending code, the state it clobbers, and the fix all live in
Expensify/App, this is a frontend bug and the App deploy is correctly blocked.Targeted-fix alternative (if rolling forward): don't let the search re-seed effect overwrite a carousel that was seeded for the currently-open expense/report drilldown (e.g. bail out of
shouldWriteActiveTransactionIDsForSearchwhen the current transaction is still present in the active list, or preserve the active list across data-mutating actions like duplicate), so a background search-data refresh can no longer collapse an open carousel.- The issue is staging-only (Reproducible in production: No). PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 merged
Not repro on Win 11/Chrome build v9.4.62-4
Recording.15.mp4
- added and removed
on Aug 27, 2026 - changed the title
[-]Spend - Arrow carousel disappears after duplicating expense.[/-][+][Due for payment 2026-09-03] Spend - Arrow carousel disappears after duplicating expense.[/+]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
Type
Projects
- Status
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?: No
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): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search
Action Performed:
Prerequisite: Account has a workspace.
Prerequisite 2: Have a report with two manual expenses created on workspace chat.
Expected Result:
Arrow carousel should still be visible when returning to expense after duplicating it.
Actual Result:
Arrow carousel disappears when returning to expense after duplicating it.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7243805_1787794651457.Carousel_Disappears.mp4
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @thelullabyy