Exception replay: local variables on the throwing frame

Embed
Preview of the card
<a href="https://watchtowerops.net/docs/exception-replay"><img src="https://watchtowerops.net/docs/_api/public/orgs/aa5959cb-1a0b-4a9a-bc9a-913e7ac31cd9/spaces/b7aac181-9916-4805-b253-becc5fd2ca62/pages/7ebc1018-63ce-40f7-a739-f3d40c9cde26/social-card.svg?v=3e7ae33eec8b" alt="Exception replay: local variables on the throwing frame" width="600" height="315"></a>

When an error is captured, the variables of the innermost in-app frames can travel with it and show under their frame on the issue page ("Local variables"). Three switches keep this safe:

  1. Opt in per project. Turn on "Keep local variables SDKs attach to errors" in the project's issue settings (PATCH /v1/projects/{prj}/issue-settings with {"exception_replay": true}). While it is off, the worker drops the locals before anything is stored.

  2. Opt in per SDK. Nothing is read from a frame unless you ask.

  3. Masking. Variable names that look secret (password, token, key, auth, cookie, session, card, ssn, ...) are replaced by [Filtered] in the SDK, and again on the server together with the project's redaction patterns and safe_fields. Values are cut to 120 to 256 characters, at most 20 variables per frame and 8 frames per event.

Source

How

Python SDK

watchtower.init(..., capture_locals=True) or WT_EXCEPTION_LOCALS=1. Locals of in-app frames come from the traceback.

Node SDK

captureException(err, { locals: { orderId, cart } }). Node cannot read another frame's locals, so you name them.

Sentry SDKs

Their include_local_variables / vars already ride in the event; they are kept only when the project opted in.

Stored under contexts.exception_replay.frames[] as {function, filename, lineno, vars}.

Updated