🐛 Harden debugger error formatting for hostile values#4740
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Bundles Sizes Evolution
|
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: f1febfb | Docs | Datadog PR Page | Give us feedback! |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 03b6d4c0c6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
03b6d4c to
9c9b8ac
Compare
9c9b8ac to
f32c7a4
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f32c7a4f83
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
ae7762d to
9b05c9e
Compare
9b05c9e to
f6260d9
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f6260d9616
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
f6260d9 to
b4c641f
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b4c641f43c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!fn) { | ||
| // eslint-disable-next-line no-new-func, @typescript-eslint/no-implied-eval | ||
| fn = new Function('$dd_inspect', ...contextKeys, fnBodyTemplate) as (...args: any[]) => unknown[] | ||
| fn = new Function('$dd_inspect', '$dd_format_error', ...contextKeys, fnBodyTemplate) as ( |
There was a problem hiding this comment.
Avoid shadowing the template error helper
When the instrumented function has an argument or local named $dd_format_error and any template segment throws during evaluation, this helper parameter is duplicated by ...contextKeys and the customer value shadows the formatter passed at call time. Because debugger expression identifiers can start with $, the catch generated in compileSegments() then calls the customer value as a function and the whole template falls back to a TypeError instead of reporting the original segment error; use a collision-free binding or filter/rename helper parameters before appending context keys.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
I'll fix this in another PR
b4c641f to
eb2aef1
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eb2aef196c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
JavaScript allows throwing arbitrary values, but the debugger hook typed thrown values as Error and read message/stack unconditionally. Type thrown values as unknown, safely format non-Error throwables, and keep an empty stacktrace for the current Live Debugger UI contract. Reuse the shared browser-core isError helper for cross-realm Error detection and make it non-throwing for hostile toStringTag getters. Add unit tests covering thrown strings, cross-realm Errors, and values that cannot be coerced to strings.
eb2aef1 to
f4a6786
Compare
f4a6786 to
753205e
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 753205ed3b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (isError(obj)) { | ||
| return captureError(obj, depth, maxReferenceDepth, maxCollectionSize, maxFieldCount, maxLength, ctx) |
There was a problem hiding this comment.
Guard Error stack/cause captures
When this branch now accepts Error-like objects via isError() (for example { [Symbol.toStringTag]: 'Error', stack: new Proxy({}, { ownKeys() { throw ... } }) }), captureError() only guards the initial stack/cause getter and then calls captureValue() outside that guard. If the returned stack/cause value throws while being captured, the debugger hook can still throw; before this change the same Error-like object used the generic property path, whose per-property try covered the nested capture as well.
Useful? React with 👍 / 👎.

Motivation
Live Debugger runs inside instrumented application control flow, so debugger formatting must tolerate arbitrary JavaScript values without throwing while building snapshots.
JavaScript can throw any value, not just
Errorinstances. Debugger conditions, templates, and captures can also encounter cross-realm Errors, hostile getters, or values that cannot be coerced to strings.Changes
This PR hardens debugger error formatting and capture behavior:
unknownvalues instead of assumingErrorErrorvalues, including cross-realm ErrorsErrorvalues safely and keep an empty stacktrace for the current Live Debugger UI contract$dd_format_errorhelper into generated template code catch blocksbrowser-corehelpers for safeString()and sanitized JSON formattingTest instructions
Run the focused unit tests:
Checklist