Uh oh!
There was an error while loading. Please reload this page.
[Fizz] Push halted await to the owner stack for late-arriving I/O info - #35019
Merged
unstubbable merged 9 commits intoNov 1, 2025
Merged
Conversation
To quote from react#33634: > If an aborted task is not rendering, then this is an async abort. > Conceptually it's as if the abort happened inside the async gap. The > abort reason's stack frame won't have that on the stack so instead we > use the owner stack and debug task of any halted async debug info. This PR extends that logic to also try to resolve lazy components to find debug info that has been transferred to the inner value. In addition, we ignore any time and component info that might precede the I/O info, effectively allowing resolved I/O to also be considered for the owner stack. This is useful in a scenario where the Flight rendering might have been completed (and not prematurely aborted), but then the Fizz rendering is intentionally aborted before all chunks were received, while still allowing the remaining chunks (including I/O info for halted components) to be processed while the prerender is in the aborting state.
unstubbableforce-pushed
the
fix-push-halted-await-on-component-stack
branch
from
October 30, 2025 14:51
5d467bc to
64c896bCompareUh oh!
There was an error while loading. Please reload this page.
unstubbable
marked this pull request as ready for review
October 30, 2025 16:56
| if (typeof info.time === 'number') { | ||
| // This had an end time. Any awaits before this must have already resolved. | ||
| break; | ||
| } |
Contributor
There was a problem hiding this comment.
This bit is not right. We can't just take the last entry that's resolved since that doesn't tell us about where it was aborted.
We need another solution to this (e.g. an end time in the flight client that avoids adding debug info after some time stamp).
CollaboratorAuthor
There was a problem hiding this comment.
We're picking the first resolved entry. (I at least intended to do so, needs to be fixed!) My thinking was that this should point at the location where the I/O would have halted the component if we didn't render through fully. Any cached I/O that was awaited before wouldn't be emitted as I/O, so we shouldn't point at those lines.
CollaboratorAuthor
There was a problem hiding this comment.
I discussed your proposal with @eps1lon. Makes sense now, will implement that.
unstubbable
marked this pull request as draft
October 30, 2025 20:42
Not really happy about calling the public option `endTime` instead of `debugEndTime`, but this is following the `startTime`/`debugStartTime` naming pattern.
That's too late though. We probably need to prevent adding the debug info in the first place.
This reverts commit 665c671b0b87640d1fc52c39eb4aec4f5b0c72ee.
unstubbableforce-pushed
the
fix-push-halted-await-on-component-stack
branch
from
November 1, 2025 09:14
45bfa94 to
bd8ae71Compareunstubbable
marked this pull request as ready for review
November 1, 2025 09:20
sebmarkbage
approved these changes
Nov 1, 2025
Uh oh!
There was an error while loading. Please reload this page.
unstubbable added a commit
to unstubbable/react
that referenced
this pull request
Nov 3, 2025
In react#35019, we excluded debug I/O info from being considered for enhancing the owner stack if it resolved after the defined `endTime` option that can be passed to the Flight client. However, we should include any I/O that was awaited before that end time, even if it resolved later.
unstubbable added a commit
that referenced
this pull request
Nov 3, 2025
In #35019, we excluded debug I/O info from being considered for enhancing the owner stack if it resolved after the defined `endTime` option that can be passed to the Flight client. However, we should include any I/O that was awaited before that end time, even if it resolved later.
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
To quote from #33634:
This PR extends that logic to also try to resolve lazy components to find debug info that has been transferred to the inner value (same approach as in #34839).
In addition, we now ignore any time and component info that might follow the I/O info, effectively allowing resolved I/O to also be considered for the owner stack. This is useful in a scenario where the Flight rendering might have been completed (and not prematurely aborted), but then the Fizz rendering is intentionally aborted before all chunks were received, while still allowing the remaining chunks (including I/O info for halted components) to be processed while the prerender is in the aborting state.
An
endTimeoption can be passed to the Flight client to indicate that all debug info that arrives after this time should be ignored. When rendering in Fizz is then aborted, the late-arriving debug info that's used to enhance the owner stack only includes I/O info up to that end time.