BT-6886: fix: label unhandled promise rejections as 'Unhandled rejection'#370
Open
GT1990 wants to merge 1 commit into
Open
BT-6886: fix: label unhandled promise rejections as 'Unhandled rejection'#370GT1990 wants to merge 1 commit into
GT1990 wants to merge 1 commit into
Conversation
…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'.
GT1990
requested review from
adamcronin42,
konraddysput,
melekr and
sauce-abhisheks
melekr
approved these changes
May 14, 2026
| @@ -0,0 +1,60 @@ | |||
| import { BacktraceRequestHandler } from '@backtrace/sdk-core'; | |||
| import { BacktraceClient } from '../../src/index.js'; | |||
|
|
|||
Contributor
There was a problem hiding this comment.
Could we add a regression test for the direct unhandledRejection handler path as well?
test something like :
Suggested change
| expect(payload.attributes['error.type']).toBe('Unhandled rejection'); | |
| expect(payload.classifiers).toContain('UnhandledPromiseRejection'); |
| const rejectionTracking = require('promise/setimmediate/rejection-tracking'); | ||
|
|
||
| import { UnhandledExceptionHandler } from '../src/handlers/UnhandledExceptionHandler'; | ||
|
|
Contributor
There was a problem hiding this comment.
this is a great addition.
Could we add a Hermes path test here as well?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Issue was customer was getting failed-fetch promise rejections labeled as unhandled exceptions. They created a support request to figure out if they were actually exceptions or if our sdk reclassifies them as an exception.
After some digging turns out their error was a UnhandledPromiseRejection and our sdk was reclassifying it as a unhandled exception.
task: BT-6886
what changed
'Unhandled rejection'toBacktraceErrorTypeunhandledrejectionin browser,unhandledRejectionin node, promise rejection tracker in react-native) now stamperror.type: 'Unhandled rejection'error,uncaughtException, error boundaries, android native) still stamperror.type: 'Unhandled exception'