-
Notifications
You must be signed in to change notification settings - Fork 49.6k
[Flight] Respect displayName of Promise instances on the server #34825
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
Conversation
"name": "greeting", | ||
"start": 0, | ||
"value": { | ||
"status": "halted", |
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.
Wouldn't we expect the value here?
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.
This is an interesting one. Because the promise gets serialized by the props
to Component
before it has fully resolved, it gives up while serializing it. Later it also is awaited but then it's already serialized as part of props.
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.
Debug channel fixes this ofc.
This lets you assign a name to a Promise that's passed into first party code from third party since it otherwise would have no other stack frame to indicate its name since the whole creation stack would be in third party.
We already respect the
displayName
on the client but it's more complicated on the server because we don't only consider the exact instance passed touse()
but the whole await sequence and we can pick any Promise along the way for consideration. Therefore this also adds a change where we pick the Promise node for consideration if it has a name but no stack. Where we otherwise would've picked the I/O node.Another thing that this PR does is treat anonymous stack frames (empty url) as third party for purposes of heuristics like "hasUnfilteredFrame" and the name assignment. This lets you include these in the actual generated stacks (by overriding
filterStackFrame
) but we don't actually want them to be considered first party code in the heuristics since it ends up favoring those stacks and using internals likeFunction.all
in name assignment.