fix(browser): forward uncaught worker errors with their stack - #24210
Merged
Merged
Conversation
- Add an `error` listener in `registerWebWorker` that posts `event.error` (falling back to `event.message`) over the existing `_sentryWorkerError` channel - Add optional `kind` discriminator to `SerializedWorkerError`; a missing `kind` means rejection, so workers registered by an older SDK keep working - Rename `handleForwardedWorkerRejection` to `handleForwardedWorkerError` and branch on `kind` for both the mechanism and `eventFromUnknownInput`'s `isUnhandledRejection` argument - Report forwarded throws under the `auto.browser.web_worker.onerror` mechanism - Restrict `_eventFromRejectionWithPrimitive` to rejections so a thrown primitive is not labelled "Non-Error promise rejection" - Set `Error.stackTraceLimit = 50` in the worker, matching globalHandlersIntegration, since V8's default of 10 truncates stacks before they are forwarded - Wrap the forwarding `postMessage` so a non-cloneable reason is described instead of raising DataCloneError out of the worker's error handler - Correct the doc comment claiming globalHandlers already captures sync worker errors
d2anamaria
requested review from
andreiborza,
logaretm and
msonnb
and removed request for
a team
September 8, 2026 14:45
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
size-limit report 📦
|
Contributor
|
👋 @logaretm, @msonnb, @andreiborza — Please review this PR when you get a chance! |
The parent already holds the Worker object, so it listens for its error event and tells globalHandlers to skip the frameless copy that bubbles to window.onerror. The event is not cancelled, so the browser still prints its own report. The skip only applies once the worker announced that it forwards errors, so workers on an older SDK keep the bubbled event. Structured clone resets any error name outside the built-in set, so the worker sends the name separately and the parent restores it. When the reason cannot be cloned, the worker retries with a fresh Error that keeps message and stack, or with a normalized value for anything else. Message-only errors get a frame from the ErrorEvent location, the same way globalHandlers does.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
The ErrorEvent filename can differ from the worker script when the error comes from an imported module, so the worker forwards it and the page builds the fallback frame from it. The single-event e2e test now waits for a second worker's event instead of sleeping. The bubbled copy of the first throw is queued right behind the forwarded one, so it would arrive before that event.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
An ErrorEvent reports an unknown script as an empty string, which skipped the worker script and left the fallback frame on the page URL.
The page suppresses the bubbled copy of every error once the worker has announced itself, so a retry that posts another Error loses the error completely in browsers that cannot clone Error at all. The retry now sends a plain message and stack copy and the page rebuilds the Error.
Contributor
|
👋 @chargome — Please review this PR when you get a chance! |
logaretm
requested changes
Sep 14, 2026
logaretm
left a comment
logaretm
left a comment
Member
There was a problem hiding this comment.
Thanks for the PR, I did a quick glance over it and two things popped up.
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
logaretm
reviewed
Sep 17, 2026
logaretm
left a comment
logaretm
left a comment
Member
There was a problem hiding this comment.
Looks mostly fine to me now, one more Q tho
The page received every uncaught worker error twice: once forwarded with its stack and once bubbled to window.onerror without one. The worker now cancels its error event when, and only when, the forward succeeded, so the message-only copy never leaves the worker and nothing on the page has to correlate the two. A failed forward, a stopped listener or an older SDK all leave the bubbled report in place. A cancelled error prints nothing, so the worker logs it to keep it in DevTools. Cancelling also silences error listeners on the Worker object in the page, so the page replays the event for them with the error object attached. A dispatched event does not reach window.onerror. The e2e app also throws a primitive in the worker to show that the ErrorEvent position gives such an error a usable frame.
timfish
force-pushed
the
ana/fix/wasm/worker-uncaught
branch
from
September 17, 2026 15:34
b5a897c to
7e4d6b9
Compare
Contributor
|
👋 @chargome, @msonnb, @andreiborza — Please review this PR when you get a chance! |
A successful postMessage only proves the forward was queued. A worker that the page never added to the integration, or a page on an older bundle, would have lost the error entirely once the worker cancelled it. The page now replies to the worker's announce, and the worker cancels its error events only once it has that reply. Older workers never sent the capability, so they never receive the reply either.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 615cd67. Configure here.
…e workers The page replayed every forwarded error, so before the acknowledgement arrived listeners on the worker object ran twice, once for the native event and once for the replay. The worker now marks each forwarded error with whether it cancelled the native event, and the page replays only those. The capability travelled only on the one-shot announce, so a worker added after it was never acknowledged and kept bubbling for good. Every worker message now carries it, and the page acknowledges on the first one it sees.
…forwarded The worker no longer cancels its error events or waits for an acknowledgement from the page. The page records each forwarded error and skips the one window.onerror report that matches it, so an error thrown while the worker script first runs is no longer reported twice, and a missing forward can only cause a duplicate, never a lost error.
… test Each waitForError opens its own stream to the event proxy and events are not ordered across streams, so a separate recorder could lag behind the event that ends the test and miss it.
logaretm
approved these changes
Sep 21, 2026
logaretm
left a comment
logaretm
left a comment
Member
There was a problem hiding this comment.
Pushed some changes to reduce the back and forth for some edge cases. LGTM now.
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
3 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.
Uncaught errors thrown inside a web worker reach Sentry without a usable stack. They bubble to the page, so an event is still created, but the propagated
ErrorEventcarries no error object, only a message string. The result is an event with a single synthetic frame pointing at the worker bundle and a value prefixed withUncaught.For plain JavaScript that degrades acceptably: one frame plus a sourcemap still locates the throw. For WebAssembly it fails outright. No frame carries a wasm URL, so the wasm integration finds nothing to match and the event ships with no debug images, even though the worker's images already reached the page. An uncaught wasm trap in a worker is unsymbolicatable today, while the identical trap wrapped in try/catch symbolicates fine.
Root cause
registerWebWorkeronly forwarded unhandled rejections, on the assumption that synchronous errors were already covered by the global handlers. They are captured, but only from the message string, because an error that crosses a worker boundary loses its error object by design.Solution
Uncaught worker errors are now forwarded to the page over the same channel that already carries rejections. Structured clone preserves
message,stackandcause, so the page receives a real error and parses a real stack, the same outcome the caught path already produced. Wasm frames then match their debug images and symbolicate normally. Forwarded errors are distinguishable from rejections by their mechanism, and the worker's stack trace limit now matches the page's so deep stacks are no longer truncated before being sent.Structured clone resets any error name outside the built-in set to
Error, which would turn a wasmRuntimeErroror a custom subclass into a plainError. The worker sends the name separately and the page restores it before building the event.The throw would still bubble to the page after the worker forwards it, so the worker cancels its error event when, and only when, the forward succeeded and the page has confirmed it handles forwarded errors. The page sends that confirmation once, in reply to the first message from a worker that declared the capability, so a worker added to the integration after its announce is confirmed on its first forwarded error, and older workers never receive a message their handlers would not expect. Each forwarded error records whether the worker cancelled the native event, and the page replays it on the
Workerobject only in that case. Nothing on the page has to correlate the two reports, and a failed forward, a stopped listener, a worker the page never added to the integration or an older bundle on either side all leave the bubbled report in place. The worst case is a duplicate for an error thrown during the startup round trip. A cancelled error prints nothing, so the worker logs it to keep it visible in DevTools. Cancelling also silenceserrorlisteners on theWorkerobject in the page, so the page replays the event for them with the error object attached, which the native event never carries. A dispatched event does not reachwindow.onerror.When the error value cannot be structured-cloned, for example a
WebAssembly.Exceptionor an error whosecauseholds a function, the worker retries with a plain copy of the message and stack that clones in every browser, and the page rebuilds the error from it. Values that are not errors go throughnormalizeinstead.Errors that arrive without an error object, such as cross-origin script errors, get a frame from the
ErrorEventlocation, the same way the global handlers do.Limitations
A worker on this version paired with a page bundle on an older version still forwards, but the older page ignores the new fields and labels every forwarded error as an unhandled rejection.