Repository navigation
[Due for payment 2026-09-03] Spend - "No expenses yet" displayed on report with expenses after returning to it via arrow. #99619
Description
Activity
- addedDeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deployment
on Aug 27, 2026 - addedBugSomething 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/13b9100349661801cc61ac6616bac32804fb334a64fc0048ccc22468c7cf69bcYou 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
Causing PR: #98611 - "Standardize Expense Report and Expense header with predictable button placement and carousel counter" by @thelullabyy (High confidence)
Related Issues: N/ARecommendation: REVERT
PR #98611 reworked exactly the report/expense arrow-carousel navigation described in the repro and is the only report-carousel change in this staging release (v9.4.62-1); it is on staging but not yet in production, which matches "reproducible on staging, not on production." A revert cleanly removes the regression; if the author prefers, a targeted roll-forward fix is acceptable since they are already assigned.
Assigned: @thelullabyy (PR author), @ShridharGoel and @JS00001 (approving reviewers) — already assigned to this issue by Melvin.
Labels: No changes.DeployBlockerCashis kept (App PR caused it, and the App deploy is blocked). NoDeployBlocker(Web) label is present, so nothing to remove.📋 Detailed Analysis
Evidence
- The bug version is v9.4.62-1. PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 (merge commit
a29eb30142d79be6251894dbfd8d4443ecee1f31, merged 2026-08-26) is listed in the current StagingDeployCash checklist #99596 for release9.4.62-1, and is not yet in production — consistent with "Reproducible in staging: Yes / production: No." - The PR is a large refactor of the exact feature in the repro: the arrow carousel at the top of the report view. It rewrites both carousel components:
- Report-level carousel
MoneyRequestReportNavigation.tsx— the arrows that page between reports (goToReportId→Navigation.setParams({reportID})), plus a newisFocusedguard on the count-sync effect. - Transaction-level carousel
MoneyRequestReportTransactionsNavigation.tsx— newanchorTransactionIDnavigation param and an expandedCAROUSEL_PRESERVING_SCREENSset that changes when the active-transaction list is cleared on unmount.
- Report-level carousel
- Melvin auto-assigned this PR's author and reviewers as the offending PR, which aligns with the code-area match.
Verification
- The affected symptom ("No expenses yet") is the report empty state rendered in
MoneyRequestReportActionsList.tsxviaSearchMoneyRequestReportEmptyState, gated byisReportEmpty = isEmpty(visibleReportActions) && isEmpty(transactions) && !isInitialReportLoadPending. - PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 modifies files directly in this affected area, confirmed from the PR's file list:
src/components/MoneyRequestReportView/MoneyRequestReportNavigation.tsx,.../MoneyRequestReportTransactionsNavigation.tsx,.../MoneyRequestReportTransactionList.tsx,src/components/Search/index.tsx,src/hooks/useNavigateToTransactionThread.ts, andsrc/libs/actions/TransactionThreadNavigation.ts. - I confirmed the merged tree contains the PR's new logic:
anchorTransactionID,CAROUSEL_PRESERVING_SCREENS, and the new active-transaction seeding effect are all present.
Root Cause
The PR moved the carousel's prev/next state into a shared Onyx store (
TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS+ a new snapshot-hash key) that is now written and cleared from several places as the user pages around:- When a report with ≥2 expenses is displayed,
MoneyRequestReportTransactionList.tsxseeds the active-transaction list in an effect and clears it in the effect cleanup on unmount. Search/index.tsxadds a second seeding effect gated on the search snapshot hash (shouldWriteActiveTransactionIDsForSearch).- Navigation now carries an
anchorTransactionIDparam, and the unmount-clear guard was broadened toCAROUSEL_PRESERVING_SCREENS.
Paging away from report A to report B via the top carousel (
Navigation.setParams) unmounts A's transaction list — running the cleanup that clears the shared IDs — and re-seeds for B. On returning to A via the carousel, the interplay of the snapshot-hash gate, theanchorTransactionIDguard, and the clear-on-unmount cleanup leaves A's transaction list rendering its empty state, soisReportEmptyevaluates true and "No expenses yet" is shown even though the report's expenses still exist. The expenses are not deleted — this is a display/state regression that resolves once the report is re-opened fresh.Because the fix must happen in
Expensify/App(revert or repair PR #98611), this is a Frontend bug; the App deploy is correctly blocked byDeployBlockerCash.- The bug version is v9.4.62-1. PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #98611 (merge commit
Deploy blocker analysis
Offending PR: Expensify/App#98611 — "Standardize Expense Report and Expense header with predictable button placement and carousel counter" (merged
a29eb30, in9.4.62-1). Confirmed high confidence.Recommended action: revert #98611 (roll-forward with a targeted fix is acceptable if the author prefers).
Root cause: PR #98611 rewrote exactly the arrow-carousel navigation described in the repro and moved the active-transaction/carousel state into a shared Onyx store that is seeded and cleared from multiple sites. Paging report A → B via the top carousel unmounts A and runs its clear-on-unmount cleanup, then re-seeds for B; returning to A leaves the transaction list stuck in its empty state under the interplay of the snapshot-hash seeding gate, the new
anchorTransactionIDnavigation guard, and the clear-on-unmount. The result is theisReportEmpty"No expenses yet" empty state rendering even though the expenses still exist — a display/state regression, not data loss. This matches the "staging only, not production" signal since the PR is only on staging.Key files (all in Expensify/App, at merge commit
a29eb30)MoneyRequestReportTransactionList.tsx— seeds the active-transaction list and clears it on unmountMoneyRequestReportTransactionsNavigation.tsx/MoneyRequestReportNavigation.tsx— the rewritten carouselsSearch/index.tsx— snapshot-hash-gated seeding effectTransactionThreadNavigation.ts— newanchorTransactionIDparam / clear guard
A deeper investigation write-up is in this comment.
Automated reproduction: I attempted to reproduce this on web, but the test session rendered a blank page (0 accessibility nodes) after sign-in and never hydrated the app — an infra/session blocker, not a product finding — so the repro could not be exercised. The conclusion above rests on code evidence and the timing/scope match, both of which are strong.
Not repro on Mac 26.5.1 Safari, v9.4.62-4
Recording.2857.mp4
- removedDeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deploymentHourlyKSv2KSv2
on Aug 27, 2026 - changed the title
[-]Spend - "No expenses yet" displayed on report with expenses after returning to it via arrow.[/-][+][Due for payment 2026-09-03] Spend - "No expenses yet" displayed on report with expenses after returning to it via arrow.[/+]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): 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 two reports created on workspace. One with at least three expenses and the other one with at least one.
Expected Result:
Expenses on report should remain visible after returning to report via arrow navigation.
Actual Result:
"No expenses yet" message appears on report with expenses after returning to it via arrow carousel.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7243763_1787788038274.No_Yet.mp4
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @thelullabyy