Repository navigation
[Due for payment 2026-09-03] Expense - x of 3 is shown after deleting the third expense #99617
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/25f62e774efe281d09e1e7c507440b005656ca8e5f9c37c6103159edba6466eb- 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 You 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 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.
@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: Original issue fixed by the PR: #90366Recommendation: ROLL FORWARD
The "x of N" counter regression is caused by a self-contained flaw in the new "preserve broader carousel" heuristic introduced by #98611. A targeted fix is far less disruptive than reverting this large header-standardization PR (which also fixed #96545, #96548, #96563, #96566, #96575 and touches every
src/languages/*file). If a quick fix can't land, fall back to REVERT.Assigned: @thelullabyy (PR author), @ShridharGoel and @JS00001 (approving reviewers) — all already assigned by melvin-bot.
Labels: No changes. This is a Frontend bug soDeployBlockerCashis kept (App deploy is correctly blocked).DeployBlockerwas not present, and the issue is not reproducible in production, so no label is removed.📋 Detailed Analysis
Evidence
- The counter renders
common.currentOfTotalwithtotal: transactionIDsList.length, wheretransactionIDsListcomes from the Onyx keyTRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS— see MoneyRequestReportTransactionsNavigation.tsx#L357. So "x of 3" persisting means that Onyx list is not shrunk when a transaction is deleted. - PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 added two new guards that stop that list from being re-seeded when the current list is a subset of the previously seeded (now stale) list. Both were introduced by this PR (confirmed in the PR diff, added lines).
- Bug is a regression: reproducible on staging, not production, and Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 is in the current StagingDeployCash (#99596).
Verification
- Affected files, all modified by Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611:
MoneyRequestReportTransactionList.tsx#L615— new early-return guard that skipssetActiveTransactionIDs(visualOrderTransactionIDs)(L618).useNavigateToTransactionThread.ts#L93— skips seeding whenshouldPreserveActiveTransactionIDsreturns true, triggered byshouldPreserveBroaderCarousel: trueatMoneyRequestReportTransactionList.tsx#L680.TransactionThreadNavigation.ts#L98-L104— theshouldPreserveActiveTransactionIDssubset heuristic.
Root Cause
visualOrderTransactionIDsfilters out deleted/pending-delete transactions (L576/L578), so after deleting the 3rd expense the report's own list correctly drops to 2 IDs. But both new guards decide whether to re-seed the carousel using a "subset means preserve the broader list" check:- List effect guard:
latestActiveTransactionIDs.length >= visualOrderTransactionIDs.length && visualOrderTransactionIDs.every((id) => latestActiveTransactionIDs.includes(id))→ returns early. shouldPreserveActiveTransactionIDs:activeIDs.length > candidateIDs.length && candidateIDs.every((id) => activeIDs.includes(id))→ returns true.
After a deletion, the 2 remaining IDs are a strict subset of the stale 3-ID list, so both guards fire and the code does not call
setActiveTransactionIDs. The Onyx list stays at 3 entries, and the counter keeps showing "x of 3".The heuristic was designed to avoid clobbering a broader carousel the user drilled in from (e.g. the Spend page). It cannot distinguish "user drilled into a narrower report" from "a transaction was just deleted from the current report" — both look like "current list is a subset of the active list."
Suggested fix direction (roll forward)
Re-seed the carousel when the shrink originates from the current report itself — e.g. only preserve the broader list when the active list contains IDs that are not part of the current report's transactions (a true drill-down), and always re-seed when the current report's own set of live transactions changed. A regression test in
tests/unit/components/MoneyRequestReportTransactionsNavigation.test.tsx/tests/unit/hooks/useNavigateToTransactionThread.test.tsfor the delete-within-report case should be added.- The counter renders
Issue not reproducible as "x of N" expense counter not displayed anymore in report view. Not repro on Win 11/Chrome build v9.4.62-4
Recording.13.mp4
- removedDeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deploymentHourlyKSv2KSv2
on Aug 27, 2026 - changed the title
[-]Expense - x of 3 is shown after deleting the third expense[/-][+][Due for payment 2026-09-03] Expense - x of 3 is shown after deleting the third 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
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:
x of 2 will be shown after deleting the third expense.
Actual Result:
x of 3 is shown after deleting the third expense.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7243762_1787787921776.8.mp4
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @thelullabyy