feat(deno)!: Align remaining denoHttpIntegration options with httpIntegration - #23692
feat(deno)!: Align remaining denoHttpIntegration options with httpIntegration#23692RulaKhaled wants to merge 3 commits into
Conversation
size-limit report 📦
|
|
|
||
| return { | ||
| name: INTEGRATION_NAME, | ||
| processEvent(event: Event): Event | null { |
There was a problem hiding this comment.
The filter is processEvent on the finished transaction, not which integration created the span. So on Deno this also drops Deno.serve 404s/3xx, not only node:http. Same side effect Bun already has.
Are we good applying that Node default to Deno including Deno.serve (align with Node/Bun/spec), or should WinterCG handlers stay unfiltered?
…egration Follow-up to #23313. Declares the outgoing request hooks on denoHttpIntegration, and makes `ignoreStatusCodes` actually take effect there by sharing the status-code filtering with Node via @sentry/core.
Keep shouldFilterStatusCode private to the module, and document that Deno's status-code filter runs on the finished transaction, including Deno.serve. Co-Authored-By: Cursor Grok 4.6 <cursoragent@cursor.com>
2c0c440 to
a380532
Compare
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 a380532. Configure here.
The filter only runs on transaction events, so MIGRATION.md and the Deno JSDoc should say so. Also wait for the parent transaction in the outgoing-hooks test instead of racing beforeSendTransaction. Co-Authored-By: Cursor <cursoragent@cursor.com>

Follow-up to #23313, which aligned most of
denoHttpIntegration's option names withhttpIntegration.Outgoing request hooks
outgoingRequestHook,outgoingResponseHookandoutgoingRequestApplyCustomAttributesare now declared ondenoHttpIntegration. Core already invoked all three and Deno already spread its options through, so they fired at runtime and were only unreachable from TypeScript. The last one maps to core'sapplyCustomAttributesOnSpan, the same waytracePropagationmaps to core's option name.ignoreStatusCodesThis was declared on the shared
HttpInstrumentationOptionscontract but read by nobody in core — only Node implemented it, in its ownprocessEvent. The filtering helper and default list now live in@sentry/core, Node uses them instead of its private copy, anddenoHttpIntegrationgained aprocessEventthat applies them.Behavior change: With
traceLifecycle: 'static', Deno now drops server transactions with status codes in[[401, 404], [301, 303], [305, 399]]by default. That is the server-SDK default fortraceIgnoreStatusCodes: incoming requests that are useless for debugging (bot 404s, unhelpful redirects) should not consume span quota. Node already used this list; Bun gets it viahttpIntegration.The filter runs in
processEventon transaction events. The default'stream'lifecycle does not produce those events, so typical Deno apps are unaffected — the same limitation Node already has.Since
denoHttpIntegrationis a default integration and filters on the finished transaction rather than on its origin, this coversDeno.servetransactions too (when transaction events are produced). PassignoreStatusCodes: []to keep everything. Documented inMIGRATION.md.Kept transactions now also carry the HTTP status in the top-level
responsecontext, as in Node.Closes #23481