[Due for payment 2026-07-29] Spend - Deleted expense can be opened via previous or next button which opens not here page

[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: Money Requests

Action Performed:

Precondition:

• Have a draft expense and a deleted expense.

1. Go to staging.new.expensify.com
2. Go to Spend > Expenses.
3. Click search button on the top right.
4. Type status:draft,deleted and search.
5. Open the draft expense.
6. Click previous or next button to open deleted expense.

Expected Result:

Previous or next button should be disabled because deleted expense cannot be viewed.

Actual Result:

Deleted expense can be opened via previous or next button which 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

Bug7213115_1784602398640.11.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7213115

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/bbf391e43f255132c9043e8bfd6aceb255d3e42f345f95c70af0a45baeb6f129

[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: Fixed original issue #90366

Recommendation: ROLL FORWARD (targeted fix)

The regression is a single missing filter condition in the carousel sibling-list builder introduced by this PR. A targeted one-line fix is far safer and smaller than reverting the entire header-standardization feature, and the PR touches many unrelated components/language files that would otherwise be reintroduced churn.

Assigned: @thelullabyy (PR author), @JS00001 and @ShridharGoel (approving reviewers) from the causing PR.
Labels: No label changes. DeployBlockerCash correctly stays (App PR caused the regression; App deploy is blocked). No DeployBlocker label is present, so nothing to remove.

📋 Detailed Analysis

Evidence

• PR Standardize Expense Report and Expense header with predictable button placement and carousel counter #90403 introduced the prev/next carousel navigation for expenses opened from the Spend page. It added MoneyRequestReportView/MoneyRequestReportTransactionsNavigation.tsx and the sibling-list wiring in src/components/Search/index.tsx, plus the TRANSACTION_THREAD_NAVIGATION_* Onyx keys and src/libs/actions/TransactionThreadNavigation.ts.
• The bug is reproducible on staging only and does not exist in production — consistent with this being a brand-new feature shipped in 9.4.41-0. Melvin already auto-assigned the PR author based on the merge, and examining the diff confirms the relevance.

Verification

• The carousel's sibling transaction ID list is built in onSelectRow in src/components/Search/index.tsx:
  

  App/src/components/Search/index.tsx

  Lines 519 to 528 in f1e82a3

  	if (isTransactionItem) {
  	const siblingTransactionIDs = (filteredData as SearchListItem[])
  	.filter((t): t is TransactionListItemType => !!t && isTransactionListItemType(t) && t.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)
  	.map((t) => t.transactionID);
  	if (siblingTransactionIDs.length > 1) {
  	setActiveTransactionIDs(siblingTransactionIDs, hash);
  	} else {
  	clearActiveTransactionIDs();
  	}
  	}

  const siblingTransactionIDs = (filteredData as SearchListItem[])
      .filter((t): t is TransactionListItemType => !!t && isTransactionListItemType(t) && t.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE)
      .map((t) => t.transactionID);
  if (siblingTransactionIDs.length > 1) {
      setActiveTransactionIDs(siblingTransactionIDs, hash);
  }

  The filter only excludes transactions with a local optimistic pendingAction === DELETE. It does not exclude expenses that are already deleted server-side (returned by the status:deleted search filter).
• The navigation component drives prev/next purely off that list and enables the buttons whenever a positional neighbor exists, with no notion of "deleted":
  

  App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionsNavigation.tsx

  Lines 73 to 87 in f1e82a3

  	const currentTransactionIndex = transactionIDsList.findIndex((id) => id === currentTransactionID);
  	const {prevTransactionID, nextTransactionID} = useMemo(() => {
  	if (!transactionIDsList || transactionIDsList.length < 2) {
  	return {prevTransactionID: undefined, nextTransactionID: undefined};
  	}
  	const prevID = currentTransactionIndex > 0 ? transactionIDsList.at(currentTransactionIndex - 1) : undefined;
  	const nextID = transactionIDsList.at(currentTransactionIndex + 1);
  	return {
  	prevTransactionID: prevID,
  	nextTransactionID: nextID,
  	};
  	}, [currentTransactionIndex, transactionIDsList]);

  
  

  App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionsNavigation.tsx

  Lines 322 to 327 in f1e82a3

  	<PrevNextButtons
  	isPrevButtonDisabled={!prevTransactionID}
  	isNextButtonDisabled={!nextTransactionID}
  	onNext={onNext}
  	onPrevious={onPrevious}
  	/>

  
  Because the deleted expense is in the list, it becomes a valid prev/next target and the button is enabled — so pressing it navigates into the deleted (trash) report and renders the "not here" page.
• The app already has the correct helper to identify these, isDeletedTransaction, which treats a transaction whose reportID === CONST.REPORT.TRASH_REPORT_ID as deleted:
  

  App/src/libs/TransactionUtils/index.ts

  Lines 147 to 149 in f1e82a3

  	function isDeletedTransaction(transaction: {reportID?: string}): boolean {
  	return transaction.reportID === CONST.REPORT.TRASH_REPORT_ID;
  	}

  
  It is already used to guard the direct row-open path in SearchUIUtils.createAndOpenSearchTransactionThread:
  

  App/src/libs/SearchUIUtils.ts

  Line 2671 in f1e82a3

  const isDeleted = isDeletedTransaction(item);

  
  The carousel sibling-list builder simply failed to apply this same guard, so prev/next bypasses a check that the direct-click path respects.

Root Cause

When a status:draft,deleted search returns a deleted expense, that expense lives in the trash report (reportID === CONST.REPORT.TRASH_REPORT_ID) and comes back with no local pendingAction === DELETE. The sibling-list filter in Search/index.tsx#onSelectRow only removes optimistic pending-deletes, so the already-deleted expense is included in TRANSACTION_THREAD_NAVIGATION_TRANSACTION_IDS. MoneyRequestReportTransactionsNavigation then treats it as a valid prev/next neighbor and enables the button, and pressing it navigates into the deleted report → "not here" page. Expected behavior is that the deleted expense is not a reachable carousel target.

Recommended Fix

Exclude already-deleted transactions from the carousel list at build time, reusing the existing helper. In src/components/Search/index.tsx (lines 520-522), extend the filter:

const siblingTransactionIDs = (filteredData as SearchListItem[])
    .filter(
        (t): t is TransactionListItemType =>
            !!t &&
            isTransactionListItemType(t) &&
            t.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE &&
            !isDeletedTransaction(t),
    )
    .map((t) => t.transactionID);

This mirrors the guard already applied on the direct row-open path (SearchUIUtils.createAndOpenSearchTransactionThread), keeps the carousel counter/total accurate, and disables prev/next at the deleted-expense boundary as expected. isDeletedTransaction is exported from @libs/TransactionUtils.