[Flight] Fix debug info leaking to outer handler #34081
Merged
+54
−1
Conversation
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
gnoff
approved these changes
Aug 1, 2025
|
Comparing: 52612a7...23e895f Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
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.
The
waitForReferencecall for debug info can trigger inside a different object's initializingHandler. In that case, we can get confused by which one is the root object.We have this special case to detect if the initializing handler's object is
nulland we have an empty string key, then we should replace the root object's value with the resolved value.react/packages/react-client/src/ReactFlightClient.js
Line 1374 in 52612a7
However, if the initializing handler actually should have the value
nullthen we might get confused by this and replace it with the resolved value from a debug object. This fixes it by just using a non-empty string as the key for the waitForReference on debug value since we're not going to use it anyway.It used to be impossible to get into this state since a
nullvalue at the root couldn't have any reference inside itself but now the debug info for anullvalue can have outstanding references.However, a better fix might be using a placeholder marker object instead of null or better yet ensuring that we know which root we're initializing in the debug model.