[Due for payment 2026-07-29] Spend - Arrow buttons on expense disappear after opening expense from expense report

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.41-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90403
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@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 any expense.
   → Arrow buttons are shown on the expense RHP.
6. Click on the subtitle link under report title.
7. Open any expense.
8. Click report RHP back button twice.

Expected Result:

Arrow buttons will not disappear from expense RHP after opening expense from expense report.

Actual Result:

Arrow buttons on expense disappear after opening expense 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

Bug7213080_1784597571383.1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @thelullabyy

[applause-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[github-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:

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.

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #90403 - "Standardize Expense Report and Expense header with predictable button placement and carousel counter" by @thelullabyy (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #90403 introduced the entire prev/next expense carousel seeding logic that this bug exercises, and reverting it cleanly removes the regression since the feature is new and does not exist in production. A targeted fix is possible (see Root Cause) if a revert is undesirable, but the safest deploy-unblocking action is a revert.

Assigned: @thelullabyy (PR author), @JS00001 and @ShridharGoel (approving reviewers) from the highest-confidence causing PR only
Labels: No label changes. This is a frontend App bug, so DeployBlockerCash is correctly kept (App deploy is blocked). There is no DeployBlocker (Web) label present to remove.

📋 Detailed Analysis

Evidence

• melvin-bot auto-flagged Standardize Expense Report and Expense header with predictable button placement and carousel counter #90403, and its diff touches exactly the affected feature: the prev/next arrow (carousel) navigation in the expense/report RHP header.
• The PR is in the current StagingDeployCash (release 9.4.41-0), merged 2026-07-17, before this bug was reported on 2026-07-21.
• The bug is reproducible on staging only and is N/A on production because the carousel counter/standardized header is a new feature shipped by this PR — a strong signal the PR is the cause.
• The repro flow steps directly through the three code paths this PR added/rewrote:
  1. Step 5 (open expense from Spend > Expenses): arrows appear because Search/index.tsx#onSelectRow (added by this PR) seeds TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS with all sibling transaction IDs.
  2. Step 6 (click subtitle link → opens the expense report view): the report-view effect in MoneyRequestReportTransactionList.tsx (rewritten by this PR) may overwrite or clear those carousel IDs.
  3. Step 8 (back twice): the report view unmounts and its cleanup calls clearActiveTransactionIDs(), wiping the carousel that the underlying expense RHP still depends on.

Verification

Affected files, all modified by PR #90403:

• src/components/MoneyRequestReportView/MoneyRequestReportTransactionsNavigation.tsx — renders the arrows; the render guard is the gate for the symptom.
• src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx — seeds/overwrites/clears the carousel IDs when the report view mounts/unmounts.
• src/components/Search/index.tsx — seeds the carousel from the Spend/Expenses flat list.
• src/libs/actions/TransactionThreadNavigation.ts — the setActiveTransactionIDs / clearActiveTransactionIDs / getActiveTransactionIDs action layer backing the carousel Onyx key.

The arrows are rendered only when the shared Onyx list has 2+ entries:
src/components/MoneyRequestReportView/MoneyRequestReportTransactionsNavigation.tsx L175-177 — permalink

if (transactionIDsList.length < 2) {
    return;
}

transactionIDsList reads ONYXKEYS.TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS (L55). Once that list is cleared or overwritten with fewer than 2 IDs, the arrows disappear.

Root Cause

The prev/next arrows depend on a single shared Onyx key, TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS, that is seeded, overwritten, and cleared by multiple components introduced/reworked in this PR.

• On the Spend > Expenses flat list, Search/index.tsx#onSelectRow seeds the key with every sibling transaction (setActiveTransactionIDs(siblingTransactionIDs, hash)), so the RHP shows arrows — permalink.
• Clicking the subtitle link opens the expense report view (SEARCH_REPORT). Its effect in MoneyRequestReportTransactionList.tsx (L493-L527) decides whether to take over the carousel with the report's own visualOrderTransactionIDs, and registers a cleanup that calls clearActiveTransactionIDs() on unmount — permalink.
• When the user navigates back twice, the report view unmounts and its cleanup clears TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS. The underlying expense RHP (opened from the Spend page) still relies on that same key, so transactionIDsList.length becomes < 2 and the arrows vanish.

In short, the report-view carousel effect and its unmount cleanup clobber the Spend-page carousel state that the expense RHP beneath it still needs. The PR added guards for the analogous snapshot/descriptor-backed flows (e.g. getActiveTransactionIDs().descriptors at L507, and the membership guard at L515-L521) but the non-descriptor Spend-page → report → expense flow is not protected: the report view's clearActiveTransactionIDs() on unmount (or an overwrite that drops IDs) removes the arrows for the expense still open underneath.

A targeted fix would preserve/restore the Spend-page carousel IDs when the report view (which overlaid it) unmounts — mirroring the existing descriptor-backed guard so the report view does not clobber a carousel that belongs to the transaction thread sitting underneath it. Given the feature is new and staging-only, a straight revert of #90403 is the lowest-risk option to unblock the deploy.