Skip to content

[Due for payment 2026-09-03] Spend - x of 2 appears on the expense thread RHP after returning from expense report #99616

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): jsdnjosdodjsdionjio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

  1. Go to staging.new.expensify.com
  2. Go to workspace chat.
  3. Create two expenses.
  4. Go to Spend > Expenses.
  5. Open search router.
  6. Type group-by:from and search.
  7. Expand the group.
  8. Open any expense.
  9. Click on the report subtitle link.
  10. Open any expense.
  11. Click app back button twice.

Expected Result:

x of 2 will not appear on the expense thread RHP after returning from expense report.

Actual Result:

x of 2 appears on the expense thread RHP after returning from expense report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7243746_1787786311825.7.mp4

View all open jobs on GitHub

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

Issue OwnerCurrent Issue Owner: @thelullabyy

Activity

  1. applause-bot commented on Aug 26, 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/211062d3c9e9192d8a4eda45bb2e41d1a9a006c8b7b68890be73740bd02beae0

  2. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Aug 26, 2026
  3. melvin-bot commented on Aug 26, 2026

    @melvin-bot

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

  4. melvin-bot commented on Aug 26, 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 26, 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 26, 2026

    @melvin-bot

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

  7. github-actions commented on Aug 26, 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 26, 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: #90366 (the issue this PR implemented)

    Recommendation: ROLL FORWARD

    The x of N carousel counter is a brand-new feature added by this PR and does not exist before it, so #98611 is unambiguously the cause. Reverting a 35-file header-standardization + carousel feature is heavy-handed for a narrow, staging-only carousel-state edge case, so a targeted fix by the author is preferred (revert as fallback if no quick fix lands before deploy).

    Assigned: @thelullabyy (PR author), @ShridharGoel and @JS00001 (approving reviewers) — already auto-assigned by Melvin.
    Labels: No change. Issue carries only DeployBlockerCash; since this is a Frontend bug (fix lives in Expensify/App), that label is correctly kept and there is no DeployBlocker to remove.

    📋 Detailed Analysis

    Evidence

    Verification

    Root Cause

    This PR added persistent, cross-screen carousel state that leaks across the reported navigation flow:

    1. Opening an expense from the Spend page's flat list seeds the carousel with all sibling transaction IDs of the search, keyed by the search hash: Search/index.tsx#L580-L590. With two expenses, the list is [t1, t2], so the counter reads x of 2.
    2. The PR expanded CAROUSEL_PRESERVING_SCREENS to include SEARCH_REPORT / SEARCH_MONEY_REQUEST_REPORT / EXPENSE_REPORT: #L35-L41. The unmount cleanup skips clearActiveTransactionIDs() for those screens: #L200-L208. So clicking the report subtitle (step 9) navigates into the expense report without clearing the seeded [t1, t2] list.
    3. Opening an expense from inside that drilled-in report (step 10) intentionally preserves the broader Spend carousel instead of re-seeding it with the report's own siblings, via shouldPreserveBroaderCarousel: true: MoneyRequestReportTransactionList.tsx#L680 and useNavigateToTransactionThread.ts#L93.
    4. After backing out twice (step 11), the stale [t1, t2] list is still in Onyx and the returned expense thread's transaction is a member of it, so currentTransactionIndex !== -1 and the header re-renders x of 2 on a thread where the search carousel context is no longer appropriate.

    Suggested direction for the targeted fix (for the author to confirm against intended UX): when opening an expense from within a drilled-in expense report, either re-seed the carousel with that report's own siblings rather than preserving the broader Spend list, or scope the preserved carousel to the originating search hash so it is not treated as active once the user has navigated into a different report context. The author should confirm the intended behavior for the counter in cross-report drill-in flows before landing the fix.

  9. m-natarajan commented on Aug 27, 2026

    @m-natarajan

    Not repro on Win 11/Chrome build v9.4.62-4

    Recording.14.mp4
  10. added and removed
    ReviewingHas a PR in review
    on Aug 27, 2026
  11. changed the title [-]Spend - x of 2 appears on the expense thread RHP after returning from expense report[/-] [+][Due for payment 2026-09-03] Spend - x of 2 appears on the expense thread RHP after returning from expense report[/+] on Aug 27, 2026
  12. 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