-
Notifications
You must be signed in to change notification settings - Fork 47.4k
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] Run recreated Errors within a fake native stack #29717
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
It's in the expanded stack if you expand the little triangle. The native stack now includes the server stack. It's kind of annoying but when Chrome prints an Error object in |
This one is currently not filtering out internal frames as mentioned here: #29708 (comment) Another thing that's new is that this is the first time we are exposing a stack trace that has been previously exposed to user space. So it could've been messed with and we aren't guaranteed to be able to use |
86920e8
to
dd8f789
Compare
Seeing it now. Though the mapping is off for me with The other stackframes are mapped correctly. Only these are incorrect:
Unfortunate that you have to have devtools open while the error happens. If you open devtools afterwards, you can't expand the error. Aside: I can't copy something from the expanded error even though it's selectable |
They seem receptive and quick to respond to contributions so that might be something you can just fix with some CSS. |
I can't repro any change with Could you have left anything in the cache? Sometimes I have to clear |
The FAST_REFRESH is probably unrelated. But otherwise I can't run dev reliably. but that's an old issue. I'll try it on a new worktree though I already cleared n_m/.cache. |
82f540f
to
67ec4a3
Compare
a215691
to
26050d0
Compare
// stacks will have had the source map already applied so it's pointing to the | ||
// original source. We return a blank source map that just maps everything to | ||
// the original source in this case. | ||
if (requestedFilePath.startsWith('node:')) { |
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.
We could filter out node internals on the server for thrown errors like we do for other owner stacks.
However, the rationale for filtering those out is mainly to save on bandwidth and eval()
cost for stacks that are eagerly generated even if there is no error. If it wasn't for that it's generally up to the client to filter these out.
For errors that have actually thrown, that's less of a concern and it's nice to have the additional information if needed.
To make these automatically filtered out we can generate a source map for the internals with the ignoreList
specified so that it's hidden by default but can still be expanded if you need it for some reason.
Unfortunately ignore lists aren't applied to the default printing of reportError/console.error(error) but that's a general problem that also applies to client infra stacks.
26050d0
to
f8d12b8
Compare
); | ||
const rootTask = response._debugRootTask; | ||
if (rootTask != null) { | ||
error = rootTask.run(callStack); |
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 doesn't actually have any effect and even if it did it's not the actual component that threw. The async task doesn't get captured by the error. That might be a bug in console.createTask
. The async task that's applied is whatever task that reportError
runs in - which is whatever client component this threw inside of (<Shell>
in this case).
We could potentially restore the task of the server component that errored somehow before calling onUncaughtError
such as if the source of the error was a React.lazy
. We could also potentially annotate the error object with the server component's task. Currently we don't track which component originally threw the error.
fcc3baf
to
1fa0a71
Compare
This hides the node internals automatically but still lets them be visible when expanded.
This lets Firefox find them relatively to node: URLs
1fa0a71
to
6f16614
Compare
6f16614
to
378dbdf
Compare
If we always add sourceURL even when we have source maps, the native stack gets source mapped. This is needed when looking up a source location from an error string where the engine doesn't have access to the native reference. Async stacks are printed with native references but errors printed into the console are printed as strings and then reverse engineered back into source mapped urls. This preserves each eval as its own id. We use a separate protocol to exclude them from other Sources. Otherwise the real file and the fake file are listed right next to eachother.
378dbdf
to
c910cb1
Compare
This way Chrome knows where this is on disk and that it's not a relative path to the page's domain.
c910cb1
to
4ba415e
Compare
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.
They seem receptive and quick to respond to contributions so that might be something you can just fix with some CSS.
I see when I have the patience to clone that repo 😄
Mapping is correct now for me. Not sure why it didn't work previously.
Maybe later. They seem to intentionally cut this off in event handlers though. Filed https://issues.chromium.org/u/1/issues/345518624 in the meantime to get clarification. |
Stacked on #29740. Before: <img width="719" alt="Screenshot 2024-06-02 at 11 51 20 AM" src="https://github.com/facebook/react/assets/63648/8f79fa82-2474-4583-894e-a2329e9a6304"> After (updated with my patches to Chrome): <img width="813" alt="Screenshot 2024-06-06 at 5 16 20 PM" src="https://github.com/facebook/react/assets/63648/bcc4f52f-e0ac-4708-ac2b-9629acdff705"> Sources panel after: <img width="1188" alt="Screenshot 2024-06-06 at 5 14 21 PM" src="https://github.com/facebook/react/assets/63648/2c673fac-d32d-42e4-8fac-bb63704e4b7f"> The fake eval file is now under "React" and the real file is now under `file://` DiffTrain build for commit cc1ec60.
Stacked on #29740.
Before:
After (updated with my patches to Chrome):
Sources panel after:
The fake eval file is now under "React" and the real file is now under
file://