Skip to content

[Due for payment 2026-09-03] Spend - After deleting expense, arrow button is shown and it opens not here page #99614

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

  1. Go to staging.new.expensify.com
  2. Go to workspace chat.
  3. Create two expenses.
  4. Open any expense.
  5. Go offline.
  6. Click More > Delete > Delete.
  7. Open the other expense.
  8. Click arrow button.

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:

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

Screenshots/Videos

Bug7243730_1787784469031.06.mp4

View all open jobs on GitHub

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

Issue OwnerCurrent Issue Owner: @thelullabyy

Activity

  1. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Aug 26, 2026
  2. 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/c26716fb6ed7ea52ff3c92d335315cf85a7528c90e8e6196f3fbab70684a6ab9

  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. 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.
  6. 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

  7. melvin-bot commented on Aug 26, 2026

    @melvin-bot

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

  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: N/A

    Recommendation: 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. DeployBlockerCash is 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, and TransactionThreadNavigation.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 shouldPreserveBroaderCarousel and new function shouldPreserveActiveTransactionIDs were both added by this PR.
      • Old code: setActiveTransactionIDs(siblingTransactionIDs).then(...) — always re-seeds.
      • New code: shouldPreserveBroaderCarousel && shouldPreserveActiveTransactionIDs(siblingTransactionIDs, transactionID) ? Promise.resolve() : setActiveTransactionIDs(siblingTransactionIDs).

    Verification

    Root Cause

    Step-by-step for the repro (report with tx1, tx2):

    1. Opening tx1 seeds the active carousel TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS = [tx1, tx2].
    2. Deleting tx1 offline only marks it pendingAction = DELETE; the cached carousel list is not updated. The report-list re-seed effect early-returns because the filtered list now has < 2 entries, so it never overwrites or clears the stale [tx1, tx2].
    3. Opening tx2 calls useNavigateToTransactionThread with the correctly filtered siblingTransactionIDs = [tx2] and shouldPreserveBroaderCarousel: true. shouldPreserveActiveTransactionIDs([tx2], tx2) returns true because the stale active list [tx1, tx2] still contains tx2 and is longer than the candidate — so the stale list is preserved instead of re-seeded.
    4. MoneyRequestReportTransactionsNavigation reads transactionIDsList = [tx1, tx2] (length 2), so it renders the prev/next arrows and computes prevTransactionID = tx1. Clicking prev navigates to the deleted tx1, 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 in shouldPreserveActiveTransactionIDs when a preserved entry has been deleted. This mirrors the isTransactionPendingDelete filtering the report list already applies.


    view run

  9. m-natarajan commented on Aug 27, 2026

    @m-natarajan

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

    Recording.12.mp4
  10. 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
  11. 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