Capture exception message in browser telemetry

[archandatta]

Summary

Runtime.exceptionThrown telemetry events set console_error.data.text to CDP's generic "Uncaught" / "Uncaught (in promise)" prefix and dropped the actual error message. The message lives on the exception RemoteObject (exceptionDetails.exception), which was already parsed into the struct but never read — so consumers could see that an exception fired and where (line/column/source_url/stack), but not what it said. console.error() messages were unaffected.

Changes

• Add message to BrowserConsoleErrorEventData (openapi.yaml + regenerated oapi).
• Decode a minimal RemoteObject (description, value) and derive the message: first line of description (e.g. Error: boom) → thrown value for non-Error throws → fall back to the generic text. The full stack stays in stack_trace, so message is just the name+message line.
• message is present only on exceptionThrown-sourced events; text is left unchanged so the uncaught-vs-in-promise signal is preserved.
• Unit tests for the derivation (Error, primitive throws, fallbacks).

Test plan

• go build ./...
• go test ./lib/cdpmonitor/ -run TestExceptionMessage
• e2e: assert an injected throw new Error("...") yields console_error.data.message containing the message (needs Docker + image)
• Verify the field propagates through the public API / SDK telemetry path (kernel/kernel) — additive/back-compat; add there if it re-serializes through a typed schema

---

Note

Low Risk
Additive optional API field and localized CDP handler logic with unit tests; no auth or breaking changes to existing text behavior.

Overview
Runtime.exceptionThrown console error events now expose the real exception text via a new optional message field on BrowserConsoleErrorEventData, while text stays as CDP’s generic "Uncaught" / "Uncaught (in promise)" prefix.

The CDP monitor unmarshals the exception RemoteObject and derives message with exceptionMessage: first line of description for Error throws (stack remains in stack_trace), thrown primitives via value, unserializableValue for Symbol/BigInt, then fallback to text. OpenAPI and generated oapi types were updated; consoleAPICalled paths are unchanged.

^{Reviewed by Cursor Bugbot for commit 1c55b27. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Leading newline yields empty message

Medium Severity

The exceptionMessage function returns an empty string when a CDP exception's description begins with a newline. This occurs because the first-line extraction logic misinterprets a leading newline, resulting in a blank message field in telemetry despite the generic text fallback.

 

^{Reviewed by Cursor Bugbot for commit 77185e4. Configure here.}

[rgarcia]

reviewed the openapi.yaml change — one schema suggestion:

• server/openapi.yaml:1771 — having both text and message on BrowserConsoleErrorEventData forces consumers to learn a rule ("prefer message if present, else text"), and the required field (text) is the near-useless one on the exception path ("Uncaught"). suggest dropping message entirely and making text the full console-rendered line on the exception path — that's exactly what DevTools displays (exceptionDetails.text + " " + exception.description first line, e.g. Uncaught Error: boom), so it's zero invention over CDP, keeps one required field, and preserves the uncaught-vs-in-promise signal inside the string. since this is beta, no back-compat concern. suggested description:

  text:
    type: string
    description: >
      Human-readable error text, as the browser console would display it.
      For console.error() calls, the first argument coerced to a string.
      For uncaught exceptions, the prefix and error message, e.g.
      "Uncaught Error: boom" or "Uncaught (in promise) TypeError: x is not a function".

  implementation-wise this is a small change at handlers.go:228-229 — join p.ExceptionDetails.Text with the derived message, taking care the existing fallback-to-text in exceptionMessage doesn't produce "Uncaught Uncaught".

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1c55b27. Configure here.}

[cursor]

Valueless throws omit type label

Low Severity

exceptionMessage parses a minimal cdpRemoteObject without type, so when CDP sends a valueless primitive (e.g. throw undefined) with no description, value, or unserializableValue, it falls back to generic text instead of the thrown type. consoleArgString already uses Type in the same situation.

Additional Locations (1)

• server/lib/cdpmonitor/cdp_proto.go#L76-L81

 

^{Reviewed by Cursor Bugbot for commit 1c55b27. Configure here.}