Skip to content

[Due for payment 2026-09-03] Spend - "No expenses yet" displayed on report with expenses after returning to it via arrow. #99619

Description

@applause-bot

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.

  1. Open the staging.new.expensify.com website.
  2. Navigate to "Spend" > "Reports"
  3. Open report with more than one expense.
  4. Navigate to the other report via arrow carousel on top of report.
  5. Return to previous report via arrow carousel.
  6. Note that a "No expenses yet" message appears and expenses on report are no longer visible.

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:

  • Android: App
  • Android: mWeb Chrome
  • iOS: App
  • iOS: mWeb Safari
  • iOS: mWeb Chrome
  • Windows: Chrome
  • MacOS: Chrome Safari

Screenshots/Videos

Bug7243763_1787788038274.No_Yet.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7243763

Issue OwnerCurrent Issue Owner: @thelullabyy

Activity

  1. added
    BugSomething is broken. Auto assigns a BugZero manager.
    on Aug 27, 2026
  2. applause-bot commented on Aug 27, 2026

    @applause-bot
    Author

    While Applause doesn't embed attachments for this bug, here are the links for quick view:
    https://platform.applause.com/services/links/v1/external/13b9100349661801cc61ac6616bac32804fb334a64fc0048ccc22468c7cf69bc

  3. melvin-bot commented on Aug 27, 2026

    @melvin-bot

    You have been assigned to this deploy blocker because you recently merged this PR: #98611

  4. melvin-bot commented on Aug 27, 2026

    @melvin-bot

    @JS00001 @ShridharGoel you have been assigned to this deploy blocker because you reviewed the offending PR: #98611

  5. melvin-bot commented on Aug 27, 2026

    @melvin-bot

    @thelullabyy you have been assigned to this deploy blocker because you authored the offending PR: #98611

  6. melvin-bot commented on Aug 27, 2026

    @melvin-bot

    💬 A slack conversation has been started in #expensify-open-source

  7. github-actions commented on Aug 27, 2026

    @github-actions
    Contributor

    👋 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:

    1. Identify the pull request that introduced this issue and revert it.
    2. Find someone who can quickly fix the issue.
    3. Fix the issue yourself.
  8. MelvinBot commented on Aug 27, 2026

    @MelvinBot
    Contributor

    🔍 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/A

    Recommendation: 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. DeployBlockerCash is kept (App PR caused it, and the App deploy is blocked). No DeployBlocker (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 release 9.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 new isFocused guard on the count-sync effect.
      • Transaction-level carousel MoneyRequestReportTransactionsNavigation.tsx — new anchorTransactionID navigation param and an expanded CAROUSEL_PRESERVING_SCREENS set that changes when the active-transaction list is cleared on unmount.
    • 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.tsx via SearchMoneyRequestReportEmptyState, gated by isReportEmpty = 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, and src/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.tsx seeds the active-transaction list in an effect and clears it in the effect cleanup on unmount.
    • Search/index.tsx adds a second seeding effect gated on the search snapshot hash (shouldWriteActiveTransactionIDsForSearch).
    • Navigation now carries an anchorTransactionID param, and the unmount-clear guard was broadened to CAROUSEL_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, the anchorTransactionID guard, and the clear-on-unmount cleanup leaves A's transaction list rendering its empty state, so isReportEmpty evaluates 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 by DeployBlockerCash.

  9. MelvinBot commented on Aug 27, 2026

    @MelvinBot
    Contributor

    Deploy blocker analysis

    Offending PR: Expensify/App#98611 — "Standardize Expense Report and Expense header with predictable button placement and carousel counter" (merged a29eb30, in 9.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 anchorTransactionID navigation guard, and the clear-on-unmount. The result is the isReportEmpty "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)

    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.


    view run

  10. m-natarajan commented on Aug 27, 2026

    @m-natarajan

    Not repro on Mac 26.5.1 Safari, v9.4.62-4

    Recording.2857.mp4
  11. added and removed
    ReviewingHas a PR in review
    on Aug 27, 2026
  12. 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
  13. melvin-bot commented on Aug 27, 2026

    @melvin-bot

    @thelullabyy

    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]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions