Skip to content
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] Allow parens in filenames when parsing stackframes #30396

Merged
merged 2 commits into from
Jul 24, 2024

Conversation

eps1lon
Copy link
Collaborator

@eps1lon eps1lon commented Jul 18, 2024

Summary

Based on #30395. PR has separate commits for current behavior and proposed behavior.

filenames can have parens so we need to account for that when parsing stack frames. We found that bug when trying out the latest React Canary in Next.js and stack frames from Server Components disappeared when the error was handled by a Client error boundary. Webpack adds parens for bundling layers and parens are used in Next.js to indicate route groups (and are just generally valid characters on common operating systems).

How did you test this change?

  • Changed Regexp makes RSC error tests pass (test/development/acceptance-app/rsc-runtime-errors.test.ts: "Error overlay - RSC runtime errors > should not show the bundle layer info in the file trace"): [not for merge] Allow parens in Server stack frames vercel/next.js#68120
  • Added tests with assertions of the deserialized stack on the client and calls to findSourceMapURLCalls

Copy link

vercel bot commented Jul 18, 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 Jul 24, 2024 2:39pm

@react-sizebot
Copy link

react-sizebot commented Jul 18, 2024

Comparing: e902c45...3f6be93

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.05% 1.82 kB 1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js = 501.44 kB 501.44 kB = 89.98 kB 89.98 kB
oss-experimental/react-dom/cjs/react-dom.production.js = 6.69 kB 6.69 kB +0.05% 1.83 kB 1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js = 506.26 kB 506.26 kB = 90.68 kB 90.68 kB
facebook-www/ReactDOM-prod.classic.js = 599.78 kB 599.78 kB = 105.88 kB 105.88 kB
facebook-www/ReactDOM-prod.modern.js = 575.83 kB 575.83 kB = 102.15 kB 102.15 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against f619f24

return {error};
}
componentDidCatch(error, componentInfo) {
errors.push(error);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

using expect in React lifecycles has a couple of problems:

  1. if they fail, the error reporting is unreadable since we now have AggregateError and also the frame is pointing all throughout React internals
  2. If we'd stop calling this particular lifecycle, tests would pass.

As far as I can tell, this "persist this intermediate value and then assert after render" is widely used so this isn't a new precedence.

Comment on lines +1245 to +1279
expect({
errors: errors.map(getErrorForJestMatcher),
findSourceMapURLCalls: findSourceMapURL.mock.calls,
}).toEqual({
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Single assertions are why more helpful over multiple assertions if one of them fails. A clue for the failure reason may be in later assertions and there may not be an optimal ordering. Packing everything in a single expect gives you the full context on mismatch.

There's obviously a limit depending on the kind of assertion. But this is not one of those in my opinion.

Comment on lines +1274 to +1324
message:
'An error occurred in the Server Components render. The specific message is omitted in production' +
' builds to avoid leaking sensitive details. A digest property is included on this error instance which' +
' may provide additional details about the nature of the error.',
stack:
'Error: An error occurred in the Server Components render. The specific message is omitted in production' +
' builds to avoid leaking sensitive details. A digest property is included on this error instance which' +
' may provide additional details about the nature of the error.',
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If we agree that the pattern in this test is better, I'll rewrite the other tests and then it may be better to move this into a variable. Though we usually prefer having explicit message in tests so maybe not.

message: 'This is an error',
stack: expect.stringContaining(
'Error: This is an error\n' +
' at eval (eval at testFunction (eval at createFakeFunction (**), <anonymous>:1:35)\n' +
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not sure how createFakeFunction ends up here especially because the frame now has non-matching parens.

Comment on lines +1304 to +1305
[__filename],
[__filename],
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Interesting that we call findSourceMapURL multiple times for the same file.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Only if it is different line/column numbers. In theory we could even pass the those as arguments in case it's useful info.

It might be nice for the implementation to batch multiple line/columns into one eval too. Right now it's one eval per location - not one per file.

@eps1lon eps1lon merged commit c0b76a6 into facebook:main Jul 24, 2024
187 checks passed
@eps1lon eps1lon deleted the parse-stackframes branch July 24, 2024 18:02
felixshiftellecon added a commit to felixshiftellecon/react that referenced this pull request Jul 24, 2024
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