Skip to content

BT-6886: fix: label unhandled promise rejections as 'Unhandled rejection'#370

Open
GT1990 wants to merge 1 commit into
mainfrom
aibrahim/BT-6886/unhandled-rejection-label
Open

BT-6886: fix: label unhandled promise rejections as 'Unhandled rejection'#370
GT1990 wants to merge 1 commit into
mainfrom
aibrahim/BT-6886/unhandled-rejection-label

Conversation

@GT1990
Copy link
Copy Markdown
Contributor

@GT1990 GT1990 commented May 13, 2026

Summary

  • Adds 'Unhandled rejection' to BacktraceErrorType and uses it on the async error paths in browser, node, and react-native SDKs. Sync paths (window error event, uncaughtException, RN error handler/boundary, Android native, React error boundary) keep 'Unhandled exception'.
  • Fixes BT-6886: customer (Netflix Hub / Unity WebGL) was seeing "Failed to fetch" events surface as error.type: "Unhandled exception" even though they were unhandled promise rejections from Unity's WASM bootstrap fetch, not actual synchronous crashes.
  • The UnhandledPromiseRejection classifier already existed and was correct; the error.type attribute now matches it. Customers can filter sync crashes from async noise without union queries.

Customer-facing behavior change

Dashboards and alerts filtering on error.type = "Unhandled exception" will see fewer matches after this lands. Async rejections (likely the majority of browser/RN traffic) move to error.type = "Unhandled rejection". Existing reports keep their old labels - no data migration.

If you have hardcoded filters and want a combined view, union the two values.

What changed

File Change
packages/sdk-core/src/model/report/BacktraceErrorType.ts added 'Unhandled rejection' to the union
packages/browser/src/BacktraceClient.ts unhandledrejection listener now uses new label
packages/node/src/BacktraceClient.ts both uncaughtExceptionMonitor (branched on origin) and dedicated unhandledRejection listener now use new label
packages/react-native/src/handlers/UnhandledExceptionHandler.ts both Hermes and non-Hermes promise-rejection paths now use new label
packages/*/tests/...unhandledErrorTests.spec.ts (3 new files) regression tests asserting new label on async and old label on sync

Test plan

  • npm run lint clean
  • npm test --workspace=@backtrace/sdk-core (320 tests)
  • npm test --workspace=@backtrace/browser (59 tests, includes new regression)
  • npm test --workspace=@backtrace/node (53 tests, includes new regression)
  • npm test --workspace=@backtrace/react-native (36 tests, includes new regression)
  • Manual end-to-end against a real Backtrace endpoint (node script, browser HTML): async submitted with error.type: "Unhandled rejection", sync still "Unhandled exception". Two rxids confirmed in the test universe.
  • If anyone has a React Native or Electron app already wired up against this SDK and wants to do a quick real-device smoke check before merge, that'd be appreciated. Unit-level coverage is in place but device runs would be additive.

…promise rejections as 'Unhandled rejection'

Adds 'Unhandled rejection' to BacktraceErrorType and uses it on the
async error paths in browser, node, and react-native SDKs. Sync paths
(window 'error' event, uncaughtException, RN ErrorBoundary, Android
native) keep 'Unhandled exception'.

Unhandled promise rejections and synchronous unhandled exceptions are
distinct browser/node events with different crash semantics, but the
JS SDKs were stamping both with error.type 'Unhandled exception'. The
'UnhandledPromiseRejection' classifier already captured the truth; the
attribute now matches it. Customers can filter sync crashes from async
noise without union queries.

Verified end-to-end against a real Backtrace endpoint: async path
submits with error.type 'Unhandled rejection', sync path still
submits with 'Unhandled exception'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant