Skip to content

[Fiber] Mark error boundaries and commit phases when an error is thrown #31876

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

Merged
merged 5 commits into from
Jan 2, 2025

Conversation

sebmarkbage
Copy link
Collaborator

This tracks commit phase errors and marks the component that errored as red. These also get the errors attached to the entry.

Screenshot 2024-12-20 at 2 40 14 PM

In the render phase I just mark the Error Boundary that caught the error. We don't have access to the actual error since it's locked behind closures in the update queue. We could probably expose that someway.

Screenshot 2024-12-20 at 1 49 05 PM

Follow ups:

Since the Error Boundary doesn't commit its attempted render, we don't log those. If we did then maybe we should just mark the errored component like I do for the commit phase. We could potentially walk the list of errors and log the captured fibers and just log their entries as children.

We could also potentially walk the uncommitted Fiber tree by stashing it somewhere or even getting it from the alternate. This could be done on Suspense boundaries too to track failed hydrations.

These are the only ones marked with PerformedWork atm anyway.

This lets us customize the logging for each branch.
Ideally we'd be able to mark the component that errored but we don't commit
the failed tree. In principle we could maybe walk the work in progress.
We also keep track of the errors and log those.
@sebmarkbage sebmarkbage requested a review from acdlite December 20, 2024 19:53
Copy link

vercel bot commented Dec 20, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
react-compiler-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 2, 2025 6:31pm

@react-sizebot
Copy link

react-sizebot commented Dec 20, 2024

Comparing: 0de1233...06d4173

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable/react-dom/cjs/react-dom.production.js = 6.68 kB 6.68 kB +0.11% 1.83 kB 1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js = 511.75 kB 511.56 kB = 91.41 kB 91.39 kB
oss-experimental/react-dom/cjs/react-dom.production.js = 6.69 kB 6.69 kB +0.11% 1.83 kB 1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js = 516.53 kB 516.35 kB = 92.25 kB 92.23 kB
facebook-www/ReactDOM-prod.classic.js = 593.45 kB 593.26 kB = 104.49 kB 104.46 kB
facebook-www/ReactDOM-prod.modern.js = 583.72 kB 583.53 kB = 102.94 kB 102.91 kB
oss-experimental/react-server-dom-parcel/cjs/react-server-dom-parcel-client.edge.development.js = 109.89 kB 107.51 kB = 20.95 kB 20.45 kB
oss-experimental/react-server-dom-parcel/cjs/react-server-dom-parcel-client.node.development.js = 108.09 kB 105.71 kB = 20.60 kB 20.11 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show
Name +/- Base Current +/- gzip Base gzip Current gzip
oss-experimental/react-markup/cjs/react-markup.react-server.development.js = 520.03 kB 518.22 kB = 93.60 kB 93.27 kB
oss-stable-semver/react-server-dom-parcel/cjs/react-server-dom-parcel-client.edge.development.js = 92.67 kB 92.09 kB = 17.59 kB 17.42 kB
oss-stable/react-server-dom-parcel/cjs/react-server-dom-parcel-client.edge.development.js = 92.67 kB 92.09 kB = 17.59 kB 17.42 kB
oss-stable-semver/react-server-dom-parcel/cjs/react-server-dom-parcel-client.node.development.js = 90.86 kB 90.29 kB = 17.24 kB 17.07 kB
oss-stable/react-server-dom-parcel/cjs/react-server-dom-parcel-client.node.development.js = 90.86 kB 90.29 kB = 17.24 kB 17.07 kB
oss-experimental/react-server-dom-parcel/cjs/react-server-dom-parcel-client.edge.production.js = 55.62 kB 55.05 kB = 11.41 kB 11.23 kB
oss-stable-semver/react-server-dom-parcel/cjs/react-server-dom-parcel-client.edge.production.js = 55.07 kB 54.50 kB = 11.32 kB 11.14 kB
oss-stable/react-server-dom-parcel/cjs/react-server-dom-parcel-client.edge.production.js = 55.07 kB 54.50 kB = 11.32 kB 11.14 kB
oss-experimental/react-server-dom-parcel/cjs/react-server-dom-parcel-client.node.production.js = 54.09 kB 53.51 kB = 11.10 kB 10.92 kB
oss-stable-semver/react-server-dom-parcel/cjs/react-server-dom-parcel-client.node.production.js = 53.54 kB 52.97 kB = 11.01 kB 10.83 kB
oss-stable/react-server-dom-parcel/cjs/react-server-dom-parcel-client.node.production.js = 53.54 kB 52.97 kB = 11.01 kB 10.83 kB
oss-experimental/react-server-dom-esm/esm/react-server-dom-esm-client.browser.development.js = 145.20 kB 143.57 kB = 34.00 kB 33.70 kB
oss-experimental/react-server-dom-webpack/cjs/react-server-dom-webpack-client.node.development.js = 115.84 kB 114.03 kB = 21.74 kB 21.42 kB
oss-experimental/react-server-dom-webpack/cjs/react-server-dom-webpack-client.node.unbundled.development.js = 114.50 kB 112.70 kB = 21.48 kB 21.16 kB
oss-experimental/react-server-dom-webpack/cjs/react-server-dom-webpack-client.edge.development.js = 113.60 kB 111.79 kB = 21.61 kB 21.27 kB
oss-experimental/react-server-dom-turbopack/cjs/react-server-dom-turbopack-client.edge.development.js = 113.51 kB 111.70 kB = 21.57 kB 21.23 kB
oss-experimental/react-server-dom-turbopack/cjs/react-server-dom-turbopack-client.node.development.js = 111.76 kB 109.95 kB = 21.22 kB 20.90 kB
oss-experimental/react-server-dom-esm/cjs/react-server-dom-esm-client.node.development.js = 109.12 kB 107.32 kB = 20.74 kB 20.43 kB
oss-experimental/react-server-dom-webpack/cjs/react-server-dom-webpack-client.browser.development.js = 107.77 kB 105.96 kB = 20.57 kB 20.24 kB
oss-experimental/react-server-dom-turbopack/cjs/react-server-dom-turbopack-client.browser.development.js = 107.21 kB 105.40 kB = 20.44 kB 20.11 kB
oss-experimental/react-server-dom-parcel/cjs/react-server-dom-parcel-client.browser.development.js = 104.87 kB 103.10 kB = 19.86 kB 19.55 kB
oss-experimental/react-client/cjs/react-client-flight.development.js = 106.35 kB 104.54 kB = 19.78 kB 19.47 kB
oss-experimental/react-server-dom-esm/cjs/react-server-dom-esm-client.browser.development.js = 105.02 kB 103.22 kB = 20.05 kB 19.71 kB
oss-experimental/react-server-dom-parcel/cjs/react-server-dom-parcel-client.edge.development.js = 109.89 kB 107.51 kB = 20.95 kB 20.45 kB
oss-experimental/react-server-dom-parcel/cjs/react-server-dom-parcel-client.node.development.js = 108.09 kB 105.71 kB = 20.60 kB 20.11 kB

Generated by 🚫 dangerJS against 48f9d09

sebmarkbage added a commit that referenced this pull request Dec 28, 2024
This is similar to #31876 but for Server Components.

It marks them as errored and puts the error message in the Summary
properties.

<img width="1511" alt="Screenshot 2024-12-20 at 5 05 35 PM"
src="https://github.com/user-attachments/assets/92f11e42-0e23-41c7-bfd4-09effb25e024"
/>

This only looks at the current chunk for rejections. That means that
there might still be promises deeper that rejected but it's only the
immediate return value of the Server Component that's considered a
rejection of the component itself.
Copy link
Member

@rickhanlonii rickhanlonii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

const name = getComponentNameFromFiber(fiber);
if (name === null) {
// Skip
return;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be good to include why we can skip this in the comment, seems like it should only be know for the Throw case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same the render pass but I don't love this technique. It's just a way for things like internal Fibers to be excluded from DevTools. Like the HostRoot. We use this elsewhere for things like stack frames. It doesn't really actually make sense because like the internal Offscreen component can now sometimes be visible and they should probably have the name Activity at least the way the layering is set up now. We should figure out something more explicit.

@@ -404,6 +429,24 @@ export function recordEffectDuration(fiber: Fiber): void {
}
}

export function recordEffectError(errorInfo: CapturedValue<mixed>): void {
if (!enableProfilerTimer || !enableProfilerCommitHooks) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this have a check for enableComponentPerformanceTrack? I don't know what all these flags do, but the calls above are flagged behind that and not enableProfilerCommitHooks

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a little unclear but if the other DevTools profiler wanted to use this information it could as long as enableProfilerCommitHooks was enabled. It's just not used today.

We should really probably just make sure that the enableProfilerCommitHooks flag is always gated by enableProfilerTimer. That way it can be always true. Since it's always true we can just remove and ship the enableProfilerCommitHooks flag to simplify things a bit.

@sebmarkbage sebmarkbage merged commit 0de1233 into facebook:main Jan 2, 2025
18 of 20 checks passed
github-actions bot pushed a commit that referenced this pull request Jan 2, 2025
…wn (#31876)

This tracks commit phase errors and marks the component that errored as
red. These also get the errors attached to the entry.

<img width="1505" alt="Screenshot 2024-12-20 at 2 40 14 PM"
src="https://github.com/user-attachments/assets/cac3ead7-a024-4e33-ab27-2e95293c4299"
/>

In the render phase I just mark the Error Boundary that caught the
error. We don't have access to the actual error since it's locked behind
closures in the update queue. We could probably expose that someway.

<img width="949" alt="Screenshot 2024-12-20 at 1 49 05 PM"
src="https://github.com/user-attachments/assets/3032455d-d9f2-462b-9c07-7be23663ecd3"
/>

Follow ups:

Since the Error Boundary doesn't commit its attempted render, we don't
log those. If we did then maybe we should just mark the errored
component like I do for the commit phase. We could potentially walk the
list of errors and log the captured fibers and just log their entries as
children.

We could also potentially walk the uncommitted Fiber tree by stashing it
somewhere or even getting it from the alternate. This could be done on
Suspense boundaries too to track failed hydrations.

---------

Co-authored-by: Ricky <[email protected]>

DiffTrain build for [0de1233](0de1233)
github-actions bot pushed a commit that referenced this pull request Jan 2, 2025
…wn (#31876)

This tracks commit phase errors and marks the component that errored as
red. These also get the errors attached to the entry.

<img width="1505" alt="Screenshot 2024-12-20 at 2 40 14 PM"
src="https://github.com/user-attachments/assets/cac3ead7-a024-4e33-ab27-2e95293c4299"
/>

In the render phase I just mark the Error Boundary that caught the
error. We don't have access to the actual error since it's locked behind
closures in the update queue. We could probably expose that someway.

<img width="949" alt="Screenshot 2024-12-20 at 1 49 05 PM"
src="https://github.com/user-attachments/assets/3032455d-d9f2-462b-9c07-7be23663ecd3"
/>

Follow ups:

Since the Error Boundary doesn't commit its attempted render, we don't
log those. If we did then maybe we should just mark the errored
component like I do for the commit phase. We could potentially walk the
list of errors and log the captured fibers and just log their entries as
children.

We could also potentially walk the uncommitted Fiber tree by stashing it
somewhere or even getting it from the alternate. This could be done on
Suspense boundaries too to track failed hydrations.

---------

Co-authored-by: Ricky <[email protected]>

DiffTrain build for [0de1233](0de1233)
github-actions bot pushed a commit to code/lib-react that referenced this pull request Jan 2, 2025
…wn (facebook#31876)

This tracks commit phase errors and marks the component that errored as
red. These also get the errors attached to the entry.

<img width="1505" alt="Screenshot 2024-12-20 at 2 40 14 PM"
src="https://github.com/user-attachments/assets/cac3ead7-a024-4e33-ab27-2e95293c4299"
/>

In the render phase I just mark the Error Boundary that caught the
error. We don't have access to the actual error since it's locked behind
closures in the update queue. We could probably expose that someway.

<img width="949" alt="Screenshot 2024-12-20 at 1 49 05 PM"
src="https://github.com/user-attachments/assets/3032455d-d9f2-462b-9c07-7be23663ecd3"
/>

Follow ups:

Since the Error Boundary doesn't commit its attempted render, we don't
log those. If we did then maybe we should just mark the errored
component like I do for the commit phase. We could potentially walk the
list of errors and log the captured fibers and just log their entries as
children.

We could also potentially walk the uncommitted Fiber tree by stashing it
somewhere or even getting it from the alternate. This could be done on
Suspense boundaries too to track failed hydrations.

---------

Co-authored-by: Ricky <[email protected]>

DiffTrain build for [0de1233](facebook@0de1233)
github-actions bot pushed a commit to code/lib-react that referenced this pull request Jan 2, 2025
…wn (facebook#31876)

This tracks commit phase errors and marks the component that errored as
red. These also get the errors attached to the entry.

<img width="1505" alt="Screenshot 2024-12-20 at 2 40 14 PM"
src="https://github.com/user-attachments/assets/cac3ead7-a024-4e33-ab27-2e95293c4299"
/>

In the render phase I just mark the Error Boundary that caught the
error. We don't have access to the actual error since it's locked behind
closures in the update queue. We could probably expose that someway.

<img width="949" alt="Screenshot 2024-12-20 at 1 49 05 PM"
src="https://github.com/user-attachments/assets/3032455d-d9f2-462b-9c07-7be23663ecd3"
/>

Follow ups:

Since the Error Boundary doesn't commit its attempted render, we don't
log those. If we did then maybe we should just mark the errored
component like I do for the commit phase. We could potentially walk the
list of errors and log the captured fibers and just log their entries as
children.

We could also potentially walk the uncommitted Fiber tree by stashing it
somewhere or even getting it from the alternate. This could be done on
Suspense boundaries too to track failed hydrations.

---------

Co-authored-by: Ricky <[email protected]>

DiffTrain build for [0de1233](facebook@0de1233)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants