[Due for payment 2026-07-29] [$250] [DEV] Console error when opening a newly created expense on the Spend page

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.17-0 Develop
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @QichenZhu
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open the home page
2. Create a workspace expense
3. Immediately open the expense on the Spend page

Expected Result:

No console errors

Actual Result:

Console error: Cannot update a component (SearchPage) while rendering a different component ('Search)

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Simulator.Screen.Recording.-.iPhone.17.-.2026-06-23.at.22.48.53.mov

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022069421498132348594
• Upwork Job ID: 2069421498132348594
• Last Price Increase: 2026-07-07

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The Search component calls a SearchPage-owned state setter during its render phase, which is exactly what React's warning (Cannot update a component (SearchPage) while rendering a different component (Search)) flags.

The chain:

1. SearchPage owns isSearchReady state via useSearchOverlay, exposed as the onSearchContentReady callback (which calls setIsSearchReady(true)) — useSearchOverlay.tsx:68-72.
2. It's passed down to Search as the onContentReady prop: SearchPage.tsx:159 → SearchPageWide.tsx:150.
3. Inside Search, cancelNavigationSpans() calls onContentReady?.() → setIsSearchReady on the parent — Search/index.tsx:957-965.
4. cancelNavigationSpans() is invoked inline in conditional returns during render — index.tsx:1116, 1122, and the empty-state branch 1149.

When you open a just-created expense on the Spend page, the search snapshot is transiently empty/loading (the new transaction isn't in the snapshot yet), so Search takes the empty-state render bail-out, which calls cancelNavigationSpans() → onContentReady() → setIsSearchReady() on SearchPage while Search is still rendering → the warning.

The existing code already noticed render-phase setState is dangerous — the comment at index.tsx:952-954 uses a useRef for the local bail-out flag to avoid loops, but the onContentReady?.() call updates the parent, which was overlooked.

What changes do you think we should make in order to solve the problem?

Stop calling the parent's setter (onContentReady?.()) during Search's render. There is already a no-dependency useEffect right below cancelNavigationSpans (index.tsx:972-978) that runs after every commit specifically to handle the bail-out case using the didBailToFallbackState ref.

• Remove the onContentReady?.() call from inside cancelNavigationSpans (keep it setting didBailToFallbackState.current = true).
• Move the onContentReady?.() invocation into that post-commit useEffect, guarded by didBailToFallbackState.current, so the parent update happens in the commit phase instead of during render.

This defers the SearchPage state update out of Search's render phase, matching the post-commit flush pattern already in the same file, and clears the warning without changing observed behavior.

What alternative solutions did you explore? (Optional)

Make onSearchContentReady in useSearchOverlay idempotent and only invoke it from an effect on the parent side. This is more invasive than the targeted fix above. Note: the render-phase setLastNonEmptySearchResults at SearchPage.tsx:55-57 is a red herring — it updates SearchPage's own state during SearchPage's own render and does not produce this cross-component warning.

Note on severity & scope

This is a dev-only console warning (issue is tagged [DEV]); it does not affect production behavior. The repro requires opening a newly-created expense before its transaction lands in the search snapshot, which forces the transient empty-state render bail-out.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94318) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The warning is a classic React render-phase setState: during Search's render we call a state setter that belongs to the SearchPage fiber.

SearchPage calls useSearchOverlay(...) directly in its body and passes the returned onSearchContentReady down to Search as onContentReady:

• src/pages/Search/SearchPage.tsx#L123-L131 (hook call) and #L144-L160 (passes onSearchContentReady to the narrow/wide pages)
• forwarded to Search as onContentReady at SearchPageWide.tsx#L150 and SearchPageNarrow/index.tsx#L362-L404

onSearchContentReady is just a setState, and the useState lives on the SearchPage fiber (the hook is called inline in SearchPage), which is why React names the updated component SearchPage:

• src/hooks/useSearchOverlay.tsx#L68-L72 — setIsSearchReady / onSearchContentReady = () => setIsSearchReady(true)

On the Search side, onContentReady?.() is invoked synchronously during render inside cancelNavigationSpans:

• src/components/Search/index.tsx#L957-L965 — cancelNavigationSpans ends with onContentReady?.() (line 964)
• and cancelNavigationSpans() is called from the render-phase conditional returns at #L1114-L1118 (searchResults === undefined), #L1120-L1122 (hasErrors), and #L1142-L1149 (empty state).

When you create a workspace expense and immediately open it on the Spend page, the overlay is still armed (a deferred write / pre-inserted fullscreen route from the submit flow — useSearchOverlay.tsx#L68), and Search transiently renders through one of those bail-out branches (undefined/empty results). That render-phase call updates SearchPage's isSearchReady state → Cannot update a component (SearchPage) while rendering a different component (Search).

So: open newly-created expense → Search renders an undefined/empty/error bail-out branch → cancelNavigationSpans() runs during render → onContentReady?.() → setIsSearchReady on the SearchPage fiber → render-phase cross-component setState warning.

Note the existing comment at #L953-L955 already acknowledges cancelNavigationSpans runs during render (which is why didBailToFallbackState is a ref, not state) — the span bookkeeping is render-safe, but the parent setState smuggled in via onContentReady?.() is not. This is platform-agnostic (a pure render-phase update); it only surfaces as a dev console warning, which is why the issue is tagged [DEV] and noticed on iOS App.

What changes do you think we should make in order to solve the problem?

Stop calling onContentReady?.() during render and defer it to commit, reusing the bail-out convergence mechanism that already exists for exactly this purpose.

cancelNavigationSpans already records that a bail-out happened this render via didBailToFallbackState.current = true (#L963), and there is already a no-dependency post-commit useEffect keyed off that ref (#L967-L978) whose comment states it exists to run the bail-out side effect after commit.

1. Drop the render-phase onContentReady?.() from cancelNavigationSpans (keep the span-cancel + didBailToFallbackState.current = true).
2. Move the onContentReady?.() into that existing post-commit effect, firing it whenever a bail-out occurred (the overlay can also be armed by a pre-inserted route, not only a deferred write, so this signal shouldn't be gated on hasDeferredWrite):

useEffect(() => {
    if (!didBailToFallbackState.current) {
        return;
    }
    didBailToFallbackState.current = false;
    onContentReady?.();
    if (hasDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH)) {
        flushDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH);
    }
});

This keeps setIsSearchReady (the overlay dismissal) firing on the same bail-out paths, but now in the commit phase, so the warning disappears. The flush behavior is preserved. The other two onContentReady?.() call sites are already commit-safe (onLayout event at #L947-L951 and the re-arm effect at #L1025-L1031) and need no change.

Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Make onSearchContentReady itself defer the update (e.g. InteractionManager.runAfterInteractions/requestAnimationFrame around setIsSearchReady) in useSearchOverlay.tsx#L70-L72. It works, but it hides the timing bug behind an async hop in the hook and adds latency to every overlay dismissal, including the legitimate onLayout path. Fixing it at the actual render-phase caller in Search (the one place that calls the setter during render) is more precise and reuses the bail-out effect that already exists for after-commit work.

[lorretheboy]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 07:35:31 UTC.

Proposal

What is the root cause of that problem?

The console error is React's "setState in render" guard:

Cannot update a component (SearchPage) while rendering a different component (Search). To locate the bad setState() call inside Search, follow the stack trace…

The stack points straight at the culprit:

• setIsSearchReady(true) — src/hooks/useSearchOverlay.tsx (inside onSearchContentReady)
• <Search {...props} /> — src/components/Search/SearchWithNavigationDeferredMount.tsx

So while Search is rendering, it synchronously calls a callback that setStates its ancestor SearchPage. React forbids updating one component from inside another's render, hence the warning.

Concretely, the wiring is:

1. SearchPage owns the static-list overlay lifecycle via useSearchOverlay. That hook holds isSearchReady state and exposes onSearchContentReady (which calls setIsSearchReady(true) to dismiss the overlay):

   // src/hooks/useSearchOverlay.tsx
   const onSearchContentReady = () => {
       setIsSearchReady(true);
   };

2. SearchPage passes onSearchContentReady down (through SearchPageNarrow / SearchPageWide) into Search as the onContentReady prop.

3. Inside Search (src/components/Search/index.tsx), onContentReady?.() was called from cancelNavigationSpans:

   const cancelNavigationSpans = useCallback(() => {
       cancelSpan(CONST.TELEMETRY.SPAN_NAVIGATE_TO_REPORTS);
       cancelNavigateToReportsSpans();
       if (getPendingSubmitFollowUpAction()?.followUpAction === CONST.TELEMETRY.SUBMIT_FOLLOW_UP_ACTION.NAVIGATE_TO_SEARCH) {
           cancelSubmitFollowUpActionSpan();
       }
       didBailToFallbackState.current = true;
       onContentReady?.(); // ⬅️ setStates SearchPage
   }, [onContentReady]);

4. cancelNavigationSpans runs during render, not in an effect/event handler. It's invoked from the bail-out conditional returns in Search's render body — the "undefined results", "has errors", and "empty state" branches:

   if (searchResults === undefined) {
       Log.alert('[Search] Undefined search type');
       cancelNavigationSpans();          // ⬅️ during render
       return <FullPageOfflineBlockingView>{null}</FullPageOfflineBlockingView>;
   }
   // …
   if (hasErrors) {
       cancelNavigationSpans();          // ⬅️ during render
       return (/* error view */);
   }
   // …
   if (/* empty state */) {
       cancelNavigationSpans();          // ⬅️ during render
       return (/* empty view */);
   }

The repro (immediately opening a freshly created workspace expense from Search) lands in exactly one of these transient bail-out branches while the snapshot is still partial — e.g. the list is momentarily empty or the results haven't resolved. cancelNavigationSpans() fires mid-render, calls onContentReady?.(), which runs setIsSearchReady(true) on SearchPage while Search is rendering → the warning.

Notably the code already knew span-cancellation must be render-safe: didBailToFallbackState is deliberately a useRef (not state) precisely because cancelNavigationSpans runs during render. The oversight was that the onContentReady prop call — which setStates the parent — was left inside that same render-phase function.

What changes do you think we should make in order to solve the problem?

Keep the render-phase function limited to synchronous, side-effect-free bookkeeping (flipping the didBailToFallbackState ref), and defer the parent-facing onContentReady() (plus the deferred-write flush) to after commit, where updating SearchPage's state is legal.

There is already a dep-free post-commit effect that handles the bail-out case (it flushed the deferred write because the SelectionList's onLayout never mounts on a bail). We move the overlay dismissal into it.

1. Remove the onContentReady?.() call from cancelNavigationSpans (and drop the now-unused onContentReady dependency):

   const cancelNavigationSpans = useCallback(() => {
       cancelSpan(CONST.TELEMETRY.SPAN_NAVIGATE_TO_REPORTS);
       cancelNavigateToReportsSpans();
       if (getPendingSubmitFollowUpAction()?.followUpAction === CONST.TELEMETRY.SUBMIT_FOLLOW_UP_ACTION.NAVIGATE_TO_SEARCH) {
           cancelSubmitFollowUpActionSpan();
       }
       // Only flag the bail-out here. The overlay dismissal (onContentReady) and the
       // deferred-write flush are handled in the post-commit effect below, because
       // cancelNavigationSpans runs during render (inside the conditional returns) and
       // onContentReady setStates the ancestor SearchPage — doing that mid-render throws
       // "Cannot update a component while rendering a different component".
       didBailToFallbackState.current = true;
   }, []);

2. Call onContentReady?.() from the post-commit effect (which already runs after every render to catch bail-outs), alongside the existing flush:

   useEffect(() => {
       if (!didBailToFallbackState.current) {
           return;
       }
       didBailToFallbackState.current = false;
       onContentReady?.();
       if (hasDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH)) {
           flushDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH);
       }
   });

Net effect:

• setIsSearchReady(true) now runs in Search's commit phase (via the effect) instead of during its render, so React no longer sees a parent update mid-child-render → the warning is gone.
• Behavior is preserved: the overlay is still dismissed on every bail-out path, and the deferred write is still flushed. setIsSearchReady(true) is idempotent (React bails on same-value updates), so calling it once per bail commit is harmless.

Test branch: https://github.com/Expensify/App/compare/main...lorretheboy:fix/94318?expand=1

After Fix:

94318-fix.mov

Before Fix:

94318-reproduce.mov

What alternative solutions did you explore? (Optional)

• Wrap the render-phase onContentReady?.() in a microtask/queueMicrotask (or setTimeout(…, 0)). Defers the parent update out of the render, silencing the warning, but it's a band-aid: it schedules an untracked async setState that can land after unmount and reintroduces the very timing fragility we're trying to remove. Routing it through the existing post-commit effect is deterministic and cleanup-safe.
• Convert didBailToFallbackState to state and drive dismissal off a normal effect dependency. Rejected: cancelNavigationSpans runs during render, so a setState there is the original sin — it would cause the same class of problem (and re-render churn). The ref + dep-free effect pattern already in place is the correct shape; we just needed to move the parent-facing call into it.
• Lift the overlay-ready decision entirely into SearchPage (e.g. observe the same bail conditions there). More invasive, duplicates Search's internal bail logic in the parent, and couples the two components more tightly. The one-line move keeps the readiness signal owned by the component that actually knows it bailed.

[ahmdshrif]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user creates a workspace expense and immediately opens it from the Spend page, the app throws a React console error: "Cannot update a component (SearchPage) while rendering a different component ('Search)". This happens because SearchPage calls setLastNonEmptySearchResults unconditionally during its render body whenever new snapshot data arrives, which React flags as an illegal cross-component state update when a child component (Search/SearchPageNarrow) is mid-render and triggers a cascading Onyx update back into SearchPage.

What is the root cause of that problem?

In src/pages/Search/SearchPage.tsx lines 55–57, setLastNonEmptySearchResults is called directly during the render function body:

if (currentSearchResults?.data && !shouldUseLiveData && currentSearchResults !== lastNonEmptySearchResults) {
    setLastNonEmptySearchResults(currentSearchResults);
}

React permits this pattern only when the setState call is for the component currently rendering. However, the expense-creation flow triggers a rapid Onyx write that causes a child component in the Search tree to begin rendering while SearchPage itself is still in the process of rendering — React then detects that setLastNonEmptySearchResults (which targets SearchPage's state) is being invoked during a different component's render pass, producing the "Cannot update a component while rendering a different component" error. The precise trigger is the useSearchOverlay hook computing SearchStaticList overlay content during SearchPage's render when a deferred write is pending immediately after expense creation.

What changes do you think we should make in order to solve the problem?

1. src/pages/Search/SearchPage.tsx lines 55–57 — Move the setLastNonEmptySearchResults call out of the render body into a useEffect. Replace the inline if block with a useEffect(() => { if (currentSearchResults?.data && !shouldUseLiveData && currentSearchResults !== lastNonEmptySearchResults) { setLastNonEmptySearchResults(currentSearchResults); } }, [currentSearchResults, shouldUseLiveData, lastNonEmptySearchResults]);. This defers the state update to after the render is committed, eliminating the cross-component update error.
2. src/pages/Search/SearchPage.tsx — Because searchResults is computed from lastNonEmptySearchResults on lines 71–76 and the comment on lines 50–57 explicitly justifies the render-phase pattern to avoid "one stale render", the useEffect approach will introduce that one extra render. Accept this trade-off: a single extra render with a momentary flash during sorting is preferable to a React warning that can mask real bugs and cause unexpected behavior in strict mode / concurrent rendering.
3. src/pages/Search/SearchPage.tsx — Verify there are no sibling platform files (SearchPage.ios.tsx, SearchPage.android.tsx) that replicate this same pattern; if they exist, apply the same useEffect refactor.

What alternative solutions did you explore? (Optional)

Wrapping the render-phase setLastNonEmptySearchResults call in setTimeout(() => setLastNonEmptySearchResults(currentSearchResults), 0) would also defer the update, but introduces a flicker and is less idiomatic than useEffect.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @DylanDylann (External)

[dostonbunyodov0006]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Creating a workspace expense and immediately opening it on the Spend page throws:

Cannot update a component (SearchPage) while rendering a different component (Search)

React is reporting that Search, mid-render, synchronously triggers a state update in its sibling/parent SearchPage. The render is impure and the warning should never fire.

What is the root cause of that problem?

Search and SearchPage communicate through React's synchronous render tree — a callback prop that Search invokes to hand a derived value up to SearchPage. React explicitly forbids a component from updating a different component while rendering, so the moment the new expense enters the results and Search re-renders, that upward call violates the rule.

The framing that matters: this is the wrong communication channel. Two components that need to share a fact across the tree should not do it by one imperatively setState-ing the other during render. The synchronous prop-callback path makes correct timing impossible — there is no point during Search's render where calling SearchPage's setter is legal.

What changes do you think we should make in order to solve the problem?

Move the cross-component signal out of the React render tree and onto the external store both components already use (Onyx). Search writes the value with Onyx.merge from an event/effect; SearchPage reads it with useOnyx. Store writes are decoupled from render timing, and subscribers re-render independently — so there is no "update a component while rendering another," because no component is reaching into another's React state at all.

-// Search hands the value up the render tree via a callback prop
-<Search onUpdateMetadata={setMetadata} ... />
-// inside Search render:
-onUpdateMetadata(deriveFromResults(searchResults));
+// Search publishes to the shared store, off the render path
+useEffect(() => {
+    Onyx.merge(ONYXKEYS.SEARCH_METADATA, deriveFromResults(searchResults));
+}, [searchResults]);

-// SearchPage held the value as React state pushed in by the child
-const [metadata, setMetadata] = useState();
+// SearchPage subscribes to the same store key — no setter handed out
+const [metadata] = useOnyx(ONYXKEYS.SEARCH_METADATA);

Now the two components are siblings on a pub/sub bus, not parent/child wired through render. The freshly created expense updating the results triggers a store write after commit, and SearchPage re-renders from its subscription — the warning is eliminated by construction, and the same decoupling protects any other component that later needs this value.

What alternative solutions did you explore?

• Keep the callback but fire it from a useEffect instead of render. Smallest change and it silences the warning, but it preserves the render-tree coupling: the value still flows child -> parent through a prop, and any new code path that calls it during render reintroduces the bug.
• Lift the derivation into SearchPage and delete the callback. A clean fix when SearchPage can derive the value itself; but it only works if the value is purely derivable from data SearchPage already reads. The store-based channel also covers event-driven values that aren't cleanly derivable.
• Defer the update with queueMicrotask/setTimeout. Dodges the warning via timing luck, leaves a frame where the two components disagree, and can flicker the just-opened expense. Not a real fix.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022069421498132348594