Uh oh!
There was an error while loading. Please reload this page.
fix(vercelai): Avoid double-capturing v4 tool errors in orchestrion mode - #22293
Merged
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
size-limit report 📦
|
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mydea
marked this pull request as ready for review
July 15, 2026 14:03
mydea
requested review from
JPeer264, andreiborza and isaacs
and removed request for
a teamJuly 15, 2026 14:03
isaacs
approved these changes
Jul 16, 2026
isaacs
left a comment
Member
There was a problem hiding this comment.
Clearly correct, brings this into alignment with the existing OTel behavior. 👍
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 freeto 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.
In orchestrion mode, a v4 Vercel AI tool error was reported to Sentry twice: once by the channel subscriber (
captureToolError, which captured the raw error mid-execution) and again when the SDK's wrappedAI_ToolExecutionErrorbubbled up to the app's error handling (express handler, or the global unhandled-rejection handler). The two events are different objects (raw error vs. wrapper), so Sentry's already-captured dedup didn't collapse them.This also caused a flaky test:
captures error in tool in express serverused.unordered()with a singleeventexpect and matched whichever of the two error envelopes arrived first — when the express-handler envelope won the race, the tool-tag assertions failed.Root cause
The channel subscriber's tool-
executewrapper always captured the thrown error and re-threw. That capture is required on v5, whereexecuteToolsswallows the rejection intotool-errorcontent so it never surfaces otherwise. On v4 the rejection instead bubbles out of theaicall, so it is already captured by the app's error handling — making the channel capture a duplicate. The OTel integration never had this problem because it doesn't self-capture v4 thrown tool errors; it lets them bubble.Changes:
'v1'model spec version already used elsewhere in the file). On v4 it marks the tool span as errored and lets the error bubble, matching the OTel path — so a single error event is reported._sentry_active_span, reusing the exact mechanism the OTel integration already uses (onunhandledrejectionrestores it at capture time). Without this, an unhandled rejection in a non-OTel (orchestrion) process would start its own trace instead of correlating to the transaction.WeakMap<Span, OperationErrorInfo>({ callSiteSpan, toolErrorsBubbleToCaller }) written once at operation start, rather than two parallel collections.AI_ToolExecutionErrorevent correlated to the transaction, in both orchestrion and OTel modes.Fixes the flaky
suites/tracing/vercelai/test.ts > ... > captures error in tool in express server [cjs].