$ the-wire · showcase
REACT FIZZ TIGHTENS ABORT SEMANTICS, FIXES WORK SCHEDULING VISIBILITY
By RepoJournal · Filed · About Meta · Composed from the cited sources · methodology
React's server-side rendering layer just became harder to misuse, with three commits that eliminate footguns in error handling and work scheduling that could silently swallow failures.
React Fizz is enforcing stricter abort semantics across three coordinated changes landing in the same window. First, abort reentrancy is now explicitly forbidden [1]. Previously you could contrive sequences where onError fired after a render already fataled, creating hard-to-debug timing issues. Now the request state machine rejects any abort attempt on a request that's already aborting, completed, or fataled. Second, when an abort does occur, all pending task errors now report correctly [2]. The old behavior let fatal errors suppress error reporting from tasks inside Suspense boundaries, making it impossible to surface what actually went wrong during an abort sequence. Third, Fizz's external work scheduling is now modeled explicitly in config [3], solving a reasoning problem: you could call scheduleWork with no guarantee it would execute in certain bundle configurations. These changes don't add features. They remove ways the system can lie to you about what happened.
Action items
- → Review your Fizz abort handling and error callbacks for timing-dependent logic facebook/react [plan]
- → If you drive Fizz through external performWork calls, verify your scheduling config after upgrading facebook/react [plan]
References
- [1] [Fizz] Do not allow abort reentrancy ↗ facebook/react
- [2] [Fizz] Continue reporting aborted task errors after a fatal abort ↗ facebook/react
- [3] [Fizz] model fb bundle's external work scheduling explicitly ↗ facebook/react
