[Flight] Don't call onError/onPostpone when halting and unify error branches #31715
+78
−168
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
gnoff
approved these changes
Dec 10, 2024
gnoff
approved these changes
Dec 10, 2024
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 10, 2024
…ranches (facebook#31715) We shouldn't call onError/onPostpone when we halt a stream because that node didn't error yet. Its digest would also get lost. We also have a lot of error branches now for thenables and streams. This unifies them under erroredTask. I'm not yet unifying the cases that don't allocate a task for the error when those are outlined. DiffTrain build for [4a8fc0f](facebook@4a8fc0f)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 10, 2024
…ranches (facebook#31715) We shouldn't call onError/onPostpone when we halt a stream because that node didn't error yet. Its digest would also get lost. We also have a lot of error branches now for thenables and streams. This unifies them under erroredTask. I'm not yet unifying the cases that don't allocate a task for the error when those are outlined. DiffTrain build for [4a8fc0f](facebook@4a8fc0f)
gnoff
added a commit
to vercel/next.js
that referenced
this pull request
Dec 10, 2024
…ic (#73751) Instead of relying on onError just use the timing of the prerender resolution to determine whether the server render completed before aborting. React is going to remove onError and onPostpone calls from `prerender` in flight [31715](facebook/react#31715). This is because semantically the error is going to be hidden from the prerender and on resume it might not error. So rather than relying on whether the error callback is called we simply infer whether we are done by checking if the `prerender` resolved prior to our abort deadline. In our case it is possible we also aborted earlier than the deadline because you can call something like `Math.random()` which requires the `prerender` to halt synchronously so we also check the signal status in our deadline task. We don't expect this to change any semantics so there are no altered tests. This is only currently implemented in the dynamicIO + PPR case because that is the only case using experimental React with `prerender`. When dynamicIO is on by itself we still use `renderToReadableStream` which does not have halt semantics. We will switch to `prerender` when it is available in React's stable channel
sebmarkbage
added a commit
that referenced
this pull request
Dec 11, 2024
Stacked on #31715. This adds profiling data for Server Components to the RSC stream (but doesn't yet use it for anything). This is on behind `enableProfilerTimer` which is on for Dev and Profiling builds. However, for now there's no Profiling build of Flight so in practice only in DEV. It's gated on `enableComponentPerformanceTrack` which is experimental only for now. We first emit a timeOrigin in the beginning of the stream. This provides us a relative time to emit timestamps against for cross environment transfer so that we can log it in terms of absolute times. Using this as a separate field allows the actual relative timestamps to be a bit more compact representation and preserves floating point precision. We emit a timestamp before emitting a Server Component which represents the start time of the Server Component. The end time is either when the next Server Component starts or when we finish the task. We omit the end time for simple tasks that are outlined without Server Components. By encoding this as part of the debugInfo stream, this information can be forwarded between Server to Server RSC.
This was referenced Dec 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We shouldn't call onError/onPostpone when we halt a stream because that node didn't error yet. Its digest would also get lost.
We also have a lot of error branches now for thenables and streams. This unifies them under erroredTask. I'm not yet unifying the cases that don't allocate a task for the error when those are outlined.