Skip to content

fix(sdk): drop handled third-party errors in beforeSend to reduce alert noise#119453

Draft
billyvg wants to merge 1 commit into
masterfrom
claude/serene-cannon-pzdg2q
Draft

fix(sdk): drop handled third-party errors in beforeSend to reduce alert noise#119453
billyvg wants to merge 1 commit into
masterfrom
claude/serene-cannon-pzdg2q

Conversation

@billyvg

@billyvg billyvg commented Jul 11, 2026

Copy link
Copy Markdown
Member

Context

This PR was created in response to a Sentry webhook alert received by the Claude automated session: https://claude.ai/code/session_01DoEYiubDpVgZv6GepfzYtd

Problem

A Sentry alert fired for event b37780c91da546a9a209ccf4f14d43f5 — a TypeError: Converting circular structure to JSON on the /unsubscribe/issue/:id/ transaction.

Evidence this is browser extension noise, not a Sentry bug:

  • Tagged third_party_code: True by thirdPartyErrorFilterIntegration
  • Tagged handled: yes — caught by React's ErrorBoundary before surfacing
  • Stack trace originates from <anonymous> code (classic browser extension injection pattern), not Sentry's own source files
  • The anonymous code was calling JSON.stringify on an HTMLAnchorElement that had React fiber nodes attached (__reactFiber$...), a circular-reference pattern exclusively caused by external scripts trying to serialize DOM elements that React has hydrated
  • The Sentry CDN frames in the stack (s1.sentry-cdn.com/...) are React's reconciler responding to the DOM mutation, not the root cause

Root Cause

thirdPartyErrorFilterIntegration is configured with behaviour: 'apply-tag-if-contains-third-party-frames', which tags events as third_party_code: True but does not drop them. Handled third-party errors are therefore sent to Sentry and can trigger alerts, even though they provide no actionable signal.

Fix

Add isHandledThirdPartyError predicate to beforeSend that returns null (drops the event) when:

  1. All exception values have mechanism.handled !== false (the error was caught), AND
  2. The event is tagged third_party_code: True

Unhandled third-party errors are intentionally preserved — they can still crash the page and may be worth investigating.

This is consistent with existing beforeSend filters (isFilteredRequestErrorEvent, isEventWithFileUrl, isNullTupleUnhandledRejectionEvent) that drop other categories of unactionable noise.

Changes

  • static/app/bootstrap/initializeSdk.tsx: Add isHandledThirdPartyError filter and wire into beforeSend
  • static/app/bootstrap/initializeSdk.spec.tsx: Add unit tests covering all four cases (handled+third-party, unhandled+third-party, handled+first-party, no exception)

Generated by Claude Code

The `thirdPartyErrorFilterIntegration` is configured with
`apply-tag-if-contains-third-party-frames`, which tags events as
`third_party_code: True` but does not drop them. This causes alerts to
fire for errors originating from browser extensions or injected scripts
that are already caught by React ErrorBoundaries and are not actionable.

Add `isHandledThirdPartyError` to filter out events where all exceptions
are handled and the event is tagged as third-party code. Unhandled
third-party errors are kept since they may still crash the page.
@github-actions github-actions Bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Jul 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Frontend Automatically applied to PRs that change frontend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants