-
Notifications
You must be signed in to change notification settings - Fork 50.2k
[Flight] Resolve Deep Cycles #33664
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Flight] Resolve Deep Cycles #33664
Conversation
unstubbable
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love it!
I haven't been able to construct a normal scenario where this would break. So this doesn't fail any tests.
This actually fixes vercel/next.js#72104, and we can close #32316 (an inferior solution). I've added the test from that PR to this one.
|
Oh weird. I actually originally had that test in this branch but I didn't think it would fix it. I guess I did something along the way that did fix it. |
119c751 to
7b52178
Compare
FlightReplyServer are for client->server and ReactFlightClient is for server->client. They're not 100% symmetrical. We did a number of refactors to ReactFlightClient in PRs like facebook#29823 and facebook#33664 to change the structure of the resolution. This PR brings those changes to synchronize the two approaches. Which addresses deep resolution of cycles and deferred error handling. This also fixes a critical security vulnerability.
FlightReplyServer are for client->server and ReactFlightClient is for server->client. They're not 100% symmetrical. We did a number of refactors to ReactFlightClient in PRs like #29823 and #33664 to change the structure of the resolution. This PR brings those changes to synchronize the two approaches. Which addresses deep resolution of cycles and deferred error handling. This also fixes a critical security vulnerability.
Stacked on #33666.
If we ever get a future reference to a cycle and that reference gets eagerly parsed before the target has loaded then we can end up with a cycle that never gets resolved. That's because our cycle resolution only works if the cyclic future reference is created synchronously within the parsing path of the child.
I haven't been able to construct a normal scenario where this would break. So this doesn't fail any tests. However, I can construct it with debug info since those are eagerly evaluated. It's also a prerequisite if the debug data can come out of order, like if it's on a different stream.
The fix here is to make all the internal dependencies in the "listener" list into introspectable objects instead of closures. That way we can traverse the list of dependencies of a blocked reference to see if it ends up in a cycle and therefore skip the reference.
It would be nice to address this once and for all to be more resilient to server changes, but I'm not sure if it's worth this complexity and the extra CPU cost of tracing the dependencies. Especially if it's just for debug data.
closes #32316
fixes vercel/next.js#72104