-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Include regular stack trace in serialized errors from Fizz #28684
Conversation
We previously only included the component stack. Also cleaned up the fields in Fizz server that wasn't using consistent hidden classes in dev vs prod.
escapeTextForBrowser loops over individual characters on a string and stacks can be quite large to encode.
a0dc9da
to
a5d8b9c
Compare
4255c4e
to
cebf8e1
Compare
It can be a bit confusing to see where this error came from otherwise since it didn't come from elsewhere on the client.
cebf8e1
to
e4d2591
Compare
@@ -13,7 +13,7 @@ | |||
// This should be reasonable for all loops in the source. | |||
// Note that if the numbers are too large, the tests will take too long to fail | |||
// for this to be useful (each individual test case might hit an infinite loop). | |||
const MAX_SOURCE_ITERATIONS = 1500; | |||
const MAX_SOURCE_ITERATIONS = 5000; |
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.
Why did you have to bump this?
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.
It's in the commit comment but escapeTextForBrowser is a tight loop for escaping and it easily gets up there with escaping stack traces. It's not even deterministic in our tests since it depends on your local file system what stack gets generated and how long it is.
We should probably find a way to disable this for hot loops.
We previously only included the component stack. Cleaned up the fields in Fizz server that wasn't using consistent hidden classes in dev vs prod. Added a prefix to errors serialized from server rendering. It can be a bit confusing to see where this error came from otherwise since it didn't come from elsewhere on the client. It's really kind of confusing with other recoverable errors that happen on the client too. DiffTrain build for [b9149cc](b9149cc)
Follow up to #28684. V8 includes the message in the stack and printed errors include just the stack property which is assumed to contain the message. Without this, the prefix doesn't get printed in the console. <img width="578" alt="Screenshot 2024-04-03 at 6 32 04 PM" src="https://github.com/facebook/react/assets/63648/d98a2db4-6ebc-4805-b669-59f449dfd21f"> A possible alternative would be to use a nested error with a `cause` like #28736 but that would need some more involved serializing since this prefix is coming from the server. Perhaps as a separate attribute.
Follow up to #28684. V8 includes the message in the stack and printed errors include just the stack property which is assumed to contain the message. Without this, the prefix doesn't get printed in the console. <img width="578" alt="Screenshot 2024-04-03 at 6 32 04 PM" src="https://github.com/facebook/react/assets/63648/d98a2db4-6ebc-4805-b669-59f449dfd21f"> A possible alternative would be to use a nested error with a `cause` like #28736 but that would need some more involved serializing since this prefix is coming from the server. Perhaps as a separate attribute. DiffTrain build for [583eb67](583eb67)
…28684) We previously only included the component stack. Cleaned up the fields in Fizz server that wasn't using consistent hidden classes in dev vs prod. Added a prefix to errors serialized from server rendering. It can be a bit confusing to see where this error came from otherwise since it didn't come from elsewhere on the client. It's really kind of confusing with other recoverable errors that happen on the client too.
Follow up to facebook#28684. V8 includes the message in the stack and printed errors include just the stack property which is assumed to contain the message. Without this, the prefix doesn't get printed in the console. <img width="578" alt="Screenshot 2024-04-03 at 6 32 04 PM" src="https://github.com/facebook/react/assets/63648/d98a2db4-6ebc-4805-b669-59f449dfd21f"> A possible alternative would be to use a nested error with a `cause` like facebook#28736 but that would need some more involved serializing since this prefix is coming from the server. Perhaps as a separate attribute.
We previously only included the component stack. Cleaned up the fields in Fizz server that wasn't using consistent hidden classes in dev vs prod. Added a prefix to errors serialized from server rendering. It can be a bit confusing to see where this error came from otherwise since it didn't come from elsewhere on the client. It's really kind of confusing with other recoverable errors that happen on the client too. DiffTrain build for commit b9149cc.
We previously only included the component stack.
Cleaned up the fields in Fizz server that wasn't using consistent hidden classes in dev vs prod.
Added a prefix to errors serialized from server rendering. It can be a bit confusing to see where this error came from otherwise since it didn't come from elsewhere on the client. It's really kind of confusing with other recoverable errors that happen on the client too.