[Fizz] Finish abort in a scheduled task#36580
Open
gnoff wants to merge 2 commits into
Open
Conversation
github-actions
Bot
added
the
React Core Team
There are parts of Fizz that need to schedule work regardless of whether the primary rendering pathway is drive externally through performWork. Historically scheduleWork and later s cheduleMicrotask were noops in this bundle but it makes it hard to reason about the code because you cannot be assured that calling scheduleWork will actually result in the function ever executing. Now we model this explicitly through config. For builds that drive work through external calls to performaWork we simply omit any work scheduling in startWork or pi ngTask. Now that this is modeled explicitly we can implement scheduleMicrotask and scheduleWork to actually provide a guarantee that the callbacks will get invoked. For now I've implemented these two for the fb build as synchronous however it is likely that queueMicrotask and setTimeout or similar are preferred.
`abort()` currently aborts the request synchronously. This change delays the final abort to be in a scheduled task if the renderer supports this. At the moment this doesn't sematnically change anything however it sets the stage to allow abort reason specialization by allowing pending tasks to reject with a more specific reason in between the abort start and it's completion. the change is observable in some cases however because if you are reading from the stream you might end up serializing what previously was a client rendered boudnary as a pending boundary that is then is marked client rendered in a later instruction. This also fixes a subtle error reporting issue where if the sync abort during rendering puts the request into fatal status the abort reason for the currently rendering task is not reported through onError because the request is already CLOSED or CLOSING. now by delaying the abort finish the currently rendering task always gets a chance to finish while the request is ABORTING status.
gnoff
force-pushed
the
jstory/delayed-abort
branch
from
36fb8bc to
1ffc433
Compare
gnoff
requested review from
eps1lon and
unstubbable
and removed request for
unstubbable
unstubbable
approved these changes
May 30, 2026
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 free
to 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.
abort()currently aborts the request synchronously. This change delays the final abort to be in a scheduled task if the renderer supports this. At the moment this doesn't semantically change anything however it sets the stage to allow abort reason specialization by allowing pending tasks to reject with a more specific reason in between the abort start and it's completion.the change is observable in some cases however because if you are reading from the stream you might end up serializing what previously was a client rendered boundary as a pending boundary that is then is marked client rendered in a later instruction.
This also fixes a subtle error reporting issue where if the sync abort during rendering puts the request into fatal status the abort reason for the currently rendering task is not reported through onError because the request is already CLOSED or CLOSING. now by delaying the abort finish the currently rendering task always gets a chance to finish while the request is ABORTING status.