Repository navigation
[Due for payment 2026-09-03] Spend - After deleting expense, arrow button is shown and it opens not here page #99614
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 26, 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/c26716fb6ed7ea52ff3c92d335315cf85a7528c90e8e6196f3fbab70684a6ab9You 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
github-actions commented
on Aug 26, 2026 on Aug 26, 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.
@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
🔍 Investigation Summary
Classification: Frontend bug
Causing PR: #98611 - "Standardize Expense Report and Expense header with predictable button placement and carousel counter" by @thelullabyy (High confidence)
Related Issues: N/ARecommendation: ROLL FORWARD
The regression is a narrow offline edge case, and PR #98611 is a large, foundational change (33 files: header standardization + carousel counter with many new tests). A targeted fix is far safer and cheaper than reverting the whole standardization effort.
Assigned: @thelullabyy (PR author), @ShridharGoel and @JS00001 (approving reviewers)
Labels: No changes.DeployBlockerCashis kept (App PR is the cause, and the bug is not reproducible in production so the App deploy stays blocked).DeployBlocker(Web) was not present and was not added.📋 Detailed Analysis
Evidence
- The bug is reproducible on staging (v9.4.62-1) but not on production, so the cause is a PR in the current staging deploy checklist (Deploy Checklist: New Expensify 2026-08-26 #99596, 2026-08-26).
- PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 merged 2026-08-26 13:00 UTC (same-day deploy) and rewrote the exact navigation code path in the reproduction:
MoneyRequestReportTransactionsNavigation.tsx(+233/-148),useNavigateToTransactionThread.ts, andTransactionThreadNavigation.ts. - The diff shows the PR introduced the carousel-preservation mechanism that causes the bug. Before the PR the carousel was always re-seeded on navigation; after the PR it is conditionally preserved:
- New param
shouldPreserveBroaderCarouseland new functionshouldPreserveActiveTransactionIDswere both added by this PR. - Old code:
setActiveTransactionIDs(siblingTransactionIDs).then(...)— always re-seeds. - New code:
shouldPreserveBroaderCarousel && shouldPreserveActiveTransactionIDs(siblingTransactionIDs, transactionID) ? Promise.resolve() : setActiveTransactionIDs(siblingTransactionIDs).
- New param
Verification
- Affected files (all in the PR's changeset):
- Carousel seeding/preservation:
shouldPreserveActiveTransactionIDs - Preserve decision at navigation:
useNavigateToTransactionThread.ts#L92-L93 - Arrow rendering / prev-next computation:
MoneyRequestReportTransactionsNavigation.tsx#L82and#L210
- Carousel seeding/preservation:
- The report list itself already excludes optimistically-deleted transactions when building the carousel list (
visualOrderTransactionIDs), so the regression is not in list construction but in the new preservation of a stale cached list.
Root Cause
Step-by-step for the repro (report with
tx1,tx2):- Opening
tx1seeds the active carouselTRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS = [tx1, tx2]. - Deleting
tx1offline only marks itpendingAction = DELETE; the cached carousel list is not updated. The report-list re-seed effect early-returns because the filtered list now has< 2entries, so it never overwrites or clears the stale[tx1, tx2]. - Opening
tx2callsuseNavigateToTransactionThreadwith the correctly filteredsiblingTransactionIDs = [tx2]andshouldPreserveBroaderCarousel: true.shouldPreserveActiveTransactionIDs([tx2], tx2)returnstruebecause the stale active list[tx1, tx2]still containstx2and is longer than the candidate — so the stale list is preserved instead of re-seeded. MoneyRequestReportTransactionsNavigationreadstransactionIDsList = [tx1, tx2](length 2), so it renders the prev/next arrows and computesprevTransactionID = tx1. Clicking prev navigates to the deletedtx1, which no longer resolves → "not here" page.
The core defect:
shouldPreserveActiveTransactionIDs(and the carousel consumer) treat the preserved list purely by length/membership and never account for optimistically-deleted (pendingAction = DELETE) entries.Suggested targeted fix
Filter optimistically-deleted transactions out of the effective carousel list before deciding whether to show the arrows / compute prev-next in
MoneyRequestReportTransactionsNavigation.tsx, and/or invalidate the preserved carousel inshouldPreserveActiveTransactionIDswhen a preserved entry has been deleted. This mirrors theisTransactionPendingDeletefiltering the report list already applies.
Not reproducible on Win 11/Chrome on build v9.4.62-4
Recording.12.mp4
- removedReviewingHas a PR in reviewHas a PR in reviewDeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deploymentHourlyKSv2KSv2
on Aug 27, 2026 - changed the title
[-]Spend - After deleting expense, arrow button is shown and it opens not here page[/-][+][Due for payment 2026-09-03] Spend - After deleting expense, arrow button is shown and it opens not here page[/+]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?: 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): 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:
Expected Result:
No arrow button will be shown because only one expense is in the report.
Actual Result:
Arrow button is shown and it opens not here page.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7243730_1787784469031.06.mp4
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @thelullabyy