Uh oh!
There was an error while loading. Please reload this page.
[Flight] Don't serialize toJSON in Debug path and omit wide arrays - #34759
Merged
Conversation
This shows that the Buffer is serialized its toJSON form.
…nderDebugModel This by-passes whatever toJSON generates. We want to serialize the original value. In the case of Buffer we want to serialize that as a typed array.
This helps solve it when the root value of a Promise is too large to include. In the debug channel case this would be deferred earlier.
react-sizebot
commented
Oct 7, 2025
unstubbable
approved these changes
Oct 7, 2025
Uh oh!
There was an error while loading. Please reload this page.
github-actionsBot
pushed a commit
that referenced
this pull request
Oct 7, 2025
…34759) There's a couple of issues with serializing Buffer in the debug renders. For one, the Node.js Buffer has a `toJSON` on it which turns the binary data into a JSON array which is very inefficient to serialize compared to the real buffer. For debug info we never really want to resolve these and unlike the regular render we can't error. So this uses the trick where we read the original value. It's still unfortunate that this intermediate gets created at all but at least now we're not serializing it. Second, we have a limit on depth of objects but we didn't have a limit on width like large arrays or typed arrays. This omits large arrays from the payload when possible and make them deferred when there's a debug channel. DiffTrain build for [3025aa3](3025aa3)
This was referenced Oct 7, 2025
unstubbable pushed a commit
to vercel/next.js
that referenced
this pull request
Oct 8, 2025
[diff react/react@a4eb2dfa...3025aa39](react/react@a4eb2df...3025aa3) <details> <summary>React upstream changes</summary> - react/react#34759 </details>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws (like our own ClientReference proxies) unwound the entire stringify before the replacer's per-property error handling could run. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol, like our own ClientReference proxies. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. On failure, retry the same model with one added defense: each object the replacer returns gets its properties probed the same way JSON.stringify is about to, and the values that can't be probed are replaced with the placeholder string, per value instead of per model. Since the model and traversal are identical, the retry only has to undo the failed pass: references it registered are rolled back (they describe paths into JSON that was never written and would otherwise turn the retry into self-references), the object limit it consumed is restored, and the root marker it consumed is re-armed. The successful first pass stays free of the extra reads. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 26, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
gaearon added a commit
that referenced
this pull request
Jul 27, 2026
When JSON.stringify of an outlined debug model threw, the whole model was replaced with a placeholder string. The row's type changed out from under everything that referenced it: rows that named the component as an owner now pointed at a string, references into the row's properties pointed into JSON that was never written since the references are registered while the failed pass runs, and the client threw away the rest of that component's debug info trying to initialize them. JSON.stringify reads every property of the objects the replacer returns and probes each object property's toJSON before the replacer can substitute it, so a value whose property access throws unwound the entire stringify before the replacer's per-property error handling could run. Our own ClientReference proxies exempt the toJSON probe specifically, but userland reference proxies of the same shape throw on it. The debug path already reads the original values to bypass toJSON (#34759); the probe was the remaining way for a user value to take down the whole model. Run the same probes over each object the replacer returns before JSON.stringify does. The common case is a scan that allocates nothing and returns the model as is; only a model that would have thrown gets copied, with the values that can't be probed replaced by the placeholder string, per value instead of per model. Since the pass never fails, no references are ever registered against JSON that doesn't get written. The fuzzer now exercises this: promise props are sometimes delivered behind a proxy that throws for any property access outside the thenable protocol. Values that reach a component through a userland thenable are recorded as such, since the io entry that unblocks them describes whatever context settled the thenable rather than the leaf that produced the value, and React cannot see through the thenable to forward the real chain. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There's a couple of issues with serializing Buffer in the debug renders.
For one, the Node.js Buffer has a
toJSONon it which turns the binary data into a JSON array which is very inefficient to serialize compared to the real buffer. For debug info we never really want to resolve these and unlike the regular render we can't error. So this uses the trick where we read the original value. It's still unfortunate that this intermediate gets created at all but at least now we're not serializing it.Second, we have a limit on depth of objects but we didn't have a limit on width like large arrays or typed arrays. This omits large arrays from the payload when possible and make them deferred when there's a debug channel.