-
Notifications
You must be signed in to change notification settings - Fork 47k
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] Implement captureStackTrace and owner stacks on the Server #30197
Merged
Conversation
This file contains 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
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
Opened by a member of the React Core Team
labels
Jul 2, 2024
sebmarkbage
force-pushed
the
flightownerstack
branch
from
July 3, 2024 00:42
44b566b
to
81011eb
Compare
sebmarkbage
force-pushed
the
flightownerstack
branch
from
July 3, 2024 00:49
81011eb
to
26210a1
Compare
sebmarkbage
commented
Jul 3, 2024
assertConsoleErrorDev([ | ||
'Each child in a list should have a unique "key" prop.' + | ||
' See https://react.dev/link/warning-keys for more information.\n' + | ||
' in Foo (at **)', |
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.
@rickhanlonii This test passes but "Foo" is not actually the owner stack trace because the stack starts from where the element was created and that's inside Bar.
This exposes it to captureOwnerStack(). In this case we install it permanently as we only allow one RSC renderer which then supports async contexts. It also exposes it to component stack addendums that React adds to its own console.errors. At least for now.
Since getCurrentStack is now implemented, React appends component stacks to its own logs. However, at the same time we've instrumented the console so we need to strip them back out before sending to the client. This is another reason we shouldn't append them from React.
sebmarkbage
force-pushed
the
flightownerstack
branch
from
July 3, 2024 20:58
26210a1
to
b0becf2
Compare
eps1lon
approved these changes
Jul 4, 2024
sebmarkbage
added a commit
that referenced
this pull request
Jul 4, 2024
…ing onError/onPostpone (#30206) Stacked on #30197. This is similar to #30182 and #21610 in Fizz. Track the current owner/stack/task on the task. This tracks it for attribution when serializing child properties. This lets us provide the right owner and createTask when we console.error from inside Flight itself. This also affects the way we print those logs on the client since we need the owner and stack. Now console.errors that originate on the server gets the right stack on the client: <img width="760" alt="Screenshot 2024-07-03 at 6 03 13 PM" src="https://github.com/facebook/react/assets/63648/913300f8-f364-4e66-a19d-362e8d776c64"> Unfortunately, because we don't track the stack we never pop it so it'll keep tracking for serializing sibling properties. We rely on "children" typically being the last property in the common case anyway. However, this can lead to wrong attribution in some cases where the invalid property is a next property (without a wrapping element) and there's a previous element that doesn't. E.g. `<ClientComponent title={<div />} invalid={nonSerializable} />` would use the div as the attribution instead of ClientComponent. I also wrap all of our own console.error, onError and onPostpone in the context of the parent component. It's annoying to have to remember to do this though. We could always wrap the whole rendering in such as context but it would add more overhead since this rarely actually happens. It might make sense to track the whole current task instead to lower the overhead. That's what we do in Fizz. We'd still have to remember to restore the debug task though. I realize now Fizz doesn't do that neither so the debug task isn't wrapping the console.errors that Fizz itself logs. There's something off about that Flight and Fizz implementations don't perfectly align.
This was referenced Jul 25, 2024
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.
Wire up owner stacks in Flight to the shared internals. This exposes it to
captureOwnerStack()
.In this case we install it permanently as we only allow one RSC renderer which then supports async contexts. Same thing we do for owner.
This also ends up adding it to errors logged by React through
consoleWithStackDev
. The plan is to eventually remove that but this is inline with what we do in Fizz and Fiber already.However, at the same time we've instrumented the console so we need to strip them back out before sending to the client. This lets the client control whether to add the stack back in or allowing
console.createTask
to control it.This is another reason we shouldn't append them from React but for now we hack it by removing them after the fact.