Range Day Pro

telemetry-wasm-cloud-stack

2 min read

Telemetry — WASM Call Stack to Cloud

Summary

Forward the deeper WASM call stack to Sentry Cloud. Today a WASM panic’s site (panicked at file:line:col) already forwards in the message (P3, #156), but the deeper call stack is missing — the WASM client puts it in extra.client_stack, which the relay’s ScrubbedEvent allowlist does not read. This is not a symbolication problem, is decoupled from telemetry-symbol-upload, and does not gate the prod Cloud cutover.

Context

P3 (#156) forwards crashes built from ScrubbedEvent (allowlist-by-construction). WASM panics carry their JS-side stack as an already-scrubbed string in extra.client_stack (set by libs/api-client/src/telemetry.rs); the relay never reads extra, so the Cloud event shows the panic message + location but not the full call stack.

Requirements

  • Decide between two options and implement one:
    • (a) Relay-side, minimal — carry a scrubbed extra.client_stack through ScrubbedEvent and forward it as a Sentry extra field. Smallest change; the stack shows as text. No client release needed.
    • (b) Client-side, Sentry-native — have the WASM client emit a real exception.stacktrace.frames by parsing Error.stack. Nicer (native stack view) but a client change, browser-dependent, and WASM frames are mangled without source maps.
  • Keep it scrubbed end-to-end (option (a) re-scrubs at the relay; option (b) scrubs client-side as today).

Details

  • The panic site already forwards (in the message) — this item is purely the deeper call stack.
  • Lowest priority; does not gate the prod Cloud cutover (unlike the iOS leg of telemetry-symbol-upload).

Acceptance Criteria

  • A WASM panic in Cloud shows the call stack (as extra or as frames), still scrubbed (no emails / IPs / tokens / home paths).

Open Questions

  • (a) vs (b): likely (a) first (minimal, no client release), then (b) if a native stack view is wanted later.

Graph View