fix(deno): Avoid inferring invalid span op from Deno tracer#20128
fix(deno): Avoid inferring invalid span op from Deno tracer#20128
Conversation
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Core
Other
Bug Fixes 🐛
Internal Changes 🔧
🤖 This preview updates automatically when you update the PR. |
size-limit report 📦
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
dev-packages/e2e-tests/test-applications/deno/tests/transactions.test.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit c3468bf. Configure here.
| ...options?.attributes, | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: 'manual', | ||
| [SEMANTIC_ATTRIBUTE_SENTRY_OP]: op, | ||
| ...(op ? { [SEMANTIC_ATTRIBUTE_SENTRY_OP]: op } : {}), |
There was a problem hiding this comment.
Missing SEMANTIC_ATTRIBUTE_SENTRY_OP on startSpan calls
Low Severity
The project rules require that SEMANTIC_ATTRIBUTE_SENTRY_OP is always set when calling startInactiveSpan or startSpanManual (see https://develop.sentry.dev/sdk/telemetry/traces/span-operations/). After this change, when _mapSpanKindToOp returns undefined (for INTERNAL or unspecified span kinds), no sentry.op attribute is set at all. While the previous otel.span value was non-conforming, fully omitting the op still doesn't satisfy the rule. This is flagged because it was mentioned in the rules file — this may be an intentional and justified trade-off, but it warrants explicit acknowledgment.
Additional Locations (1)
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit c3468bf. Configure here.
2 participants
Looks like an invalid span op snuck into the Deno SDK when we pick up spans from Deno's tracer. We have a
_mapSpanKindToOphelper in there which as a default value returnedotel.span. This value does not align with our definition of span ops. Instead, if we can't infer a span op, we should just not set one in the first place.(side-note: Long-term, we might need something more sophisticated here like
inferSpanDatain the Node SDK. But for now, I'd rather remove the invalid op and move on. Only came across this while working on #20127)