You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updating a context value in an already-hydrated ancestor before a streamed Suspense child that reads that context finishes streaming causes a hydration mismatch. The streamed segment was rendered on the server with the initial context value, but the client hydrates it against the updated context.
This might be similar to #22692, but the suggestions there about memoization or using startTransition don't seem to apply or fix the issue. I suspect this is related to Lazy Context Propagation.
React version: 19+
Steps To Reproduce
Within RSC, render a client context provider around a Suspense boundary whose fallback is shown while an async child suspends (e.g. await a delay, then render a component that calls useContext on that provider).
Load the page and wait for the initial shell to hydrate (provider + button are interactive; the suspended child is still pending / showing fallback).
Click the button to update the context before the suspended child’s streamed HTML arrives and hydrates (within the suspend delay, e.g. <2s in the repro below).
When the streamed boundary for the suspended child is applied and React hydrates DisplayNumber, observe a hydration error.
When the Suspense boundary resolves, React replaces the fallback UI with the server-rendered HTML. Then upon hydration, it detects a mismatch, reports an error, and regenerates the tree on the client.
The expected behavior
I'm not entirely sure. At the minimum, an error doesn't seem appropriate because the code doesn't really seem "wrong" or unidiomatic in any way. But to avoid seeing a mismatch or regenerating the tree, perhaps React should track if a streaming Suspense boundary has pending context updates, and when the streaming content resolves, apply those updates before revealing the content.
Updating a context value in an already-hydrated ancestor before a streamed
Suspensechild that reads that context finishes streaming causes a hydration mismatch. The streamed segment was rendered on the server with the initial context value, but the client hydrates it against the updated context.This might be similar to #22692, but the suggestions there about memoization or using
startTransitiondon't seem to apply or fix the issue. I suspect this is related to Lazy Context Propagation.React version: 19+
Steps To Reproduce
Suspenseboundary whose fallback is shown while an async child suspends (e.g.awaita delay, then render a component that callsuseContexton that provider).DisplayNumber, observe a hydration error.Screen.Recording.2026-06-01.at.9.14.37.PM.cropped.mp4
Link to code example: https://stackblitz.com/edit/stackblitz-starters-1km3edxy?file=app%2Fpage.tsx,app%2FClient.tsx,app%2Flayout.tsx,tsconfig.json
The current behavior
When the
Suspenseboundary resolves, React replaces the fallback UI with the server-rendered HTML. Then upon hydration, it detects a mismatch, reports an error, and regenerates the tree on the client.The expected behavior
I'm not entirely sure. At the minimum, an error doesn't seem appropriate because the code doesn't really seem "wrong" or unidiomatic in any way. But to avoid seeing a mismatch or regenerating the tree, perhaps React should track if a streaming
Suspenseboundary has pending context updates, and when the streaming content resolves, apply those updates before revealing the content.