Reports - Pagination does not appear after moving expense to a new report

[lanitochka17]

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.3.41-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83917
Email or phone of affected tester (no customers): jsodijsiodjnoidjsoj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Log in with new Gmail account.
3. Create a workspace.
4. Go to workspace chat.
5. Create two expenses.
6. Go to Reports > Reports.
7. Open the report.
8. Open any expense.
9. Click Report > Create report.

Expected Result:

Pagination will appear on report RHP.

Actual Result:

Pagination does not appear after moving expense to a new report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7107658_1773951518743.6.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[lanitochka17]

Not repro when SS off

Recording.1562.mp4

Not repro on Prod

Recording.1563.mp4

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #83917 - "Refactor search functionality to improve loading state handling" by @szymonzalarski98 (High confidence)
Related Issues: None

Recommendation: REVERT

This PR refactored how the Search component initializes by moving setup logic from the Search component to the SearchPage level (via the new useSearchPageSetup hook). This change broke the transaction preview data flow needed for pagination when viewing expenses from the Search/Reports page.

Labels: No label changes made. Both DeployBlockerCash and DeployBlocker remain, though this appears to be a frontend-only issue:

• Issue is staging-only (not reproducible in production) - per guidelines, DeployBlockerCash should remain
• Labels were added by internal team member - per guidelines, I should not remove them
• However: This is clearly a frontend bug requiring an App PR revert/fix. The DeployBlocker label (which blocks backend/Web deploy) may not be necessary since no backend changes are needed. The team should consider removing it to unblock the Web deploy while keeping DeployBlockerCash to block the App deploy.

📋 Detailed Analysis

Evidence

PR #83917 was merged on 2026-03-18 at 16:35:06Z, which aligns with the staging deploy timeline (v9.3.41-0). The issue specifically mentions this PR in the comments, and melvin-bot assigned it to the PR author.

The issue occurs when:

1. Creating expenses in a workspace
2. Opening a report from the Reports page
3. Opening an expense
4. Creating a new report from that expense (moving it)
5. Expected: Pagination arrows appear to navigate between expenses
6. Actual: Pagination does not appear

Key Changes in PR #83917

1. Moved initialization logic from Search/index.tsx to SearchPage.tsx via new useSearchPageSetup hook
2. Extracted skeleton rendering from Search component to page level (SearchLoadingSkeleton)
3. Removed openSearch() calls from Search component (moved to hook)
4. Changed component mounting order - setup now happens before Search mounts
5. Added conditional rendering of Search component based on shouldShowLoadingSkeleton

The problem appears to be related to the timing/order of when setOptimisticDataForTransactionThreadPreview is called relative to when the Search component and its context initialize.

Verification

• PR Refactor search functionality to improve loading state handling #83917 is in the current staging deploy (see StagingDeployCash Deploy Checklist: New Expensify 2026-03-19 #85862, chronological PR list position Figure out a RN version of setTimeout that works on both web and mobile #18)
• The PR modifies critical Search component initialization paths including:
  • src/components/Search/index.tsx - removed setup logic and skeleton rendering
  • src/hooks/useSearchPageSetup.ts - NEW file with extracted setup logic
  • src/hooks/useSearchLoadingState.ts - NEW file for loading state computation
  • src/pages/Search/SearchPageNarrow.tsx - added conditional rendering
  • src/pages/Search/SearchPageWide.tsx - added conditional rendering
• The issue is specific to Search/Reports functionality
• Issue is reproducible in staging but not in production (where this PR has not deployed)
• No other PRs in the staging deploy appear to affect this specific flow

Root Cause

The refactoring changed the initialization sequence of the Search component. By moving setup logic to the parent SearchPage component and introducing conditional rendering of the Search component (only when !shouldShowLoadingSkeleton), the data flow for transaction preview setup appears to have been disrupted.

Specifically, when SearchLoadingSkeleton is shown instead of the Search component, the Search component is not mounted. This means:

1. The Search component's effects and callbacks that set up transaction preview data may not run
2. The setOptimisticDataForTransactionThreadPreview call may happen without the proper context being initialized
3. Pagination data that depends on the search results context may not be properly set

This affects the pagination functionality that allows users to navigate between multiple expenses in the RHP (Right Hand Panel) after moving an expense to a new report.