feat(node): Rewrite tedious instrumentation to orchestrion tracing channels#22238
Conversation
size-limit report 📦
|
f0842ac to
9a144dd
Compare
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 9a144dd. Configure here.
| name: getSpanName(operation, databaseName, sql, request.table), | ||
| kind: SPAN_KIND.CLIENT, | ||
| attributes, | ||
| }); |
There was a problem hiding this comment.
Missing db span op attribute
Medium Severity
startInactiveSpan sets sentry.origin but never sets a span op (op: 'db' or SEMANTIC_ATTRIBUTE_SENTRY_OP). Sibling orchestrion DB integrations set this explicitly so spans stay correct outside the Node OTel inference path. Flagged because the PR review guidelines require both origin and op on every startSpan API call.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 9a144dd. Configure here.
…annels Migrate the tedious integration off the vendored `InstrumentationBase` monkey-patch onto a `node:diagnostics_channel` subscriber whose channels are injected by the orchestrion code transform. The OTel path stays as the fallback when orchestrion isn't injected. tedious is a default performance integration, so it uses the central `channelIntegrations` swap: `_init` filters the OTel `Tedious` integration out of the defaults by name and appends the channel one. No per-integration node code. The subscriber wraps the six `Connection` request methods (one db span each) and `Connection.connect` (active-database bookkeeping). Each method returns synchronously while the request settles later via its callback/events, so the subscriber owns span-ending: it wraps `request.callback` and listens for the request `error` and connection `end` events, mirroring the vendored OTel instrumentation. Fixes #20766
9a144dd to
ca2f97c
Compare
| const span = startInactiveSpan({ | ||
| name: getSpanName(operation, databaseName, sql, request.table), | ||
| kind: SPAN_KIND.CLIENT, | ||
| attributes, | ||
| }); |
There was a problem hiding this comment.
Bug: The startInactiveSpan call for the tedious integration is missing the op: 'db' field, which is present in other database integrations like mysql and postgres.
Severity: MEDIUM
Suggested Fix
Add op: 'db' to the options object passed to the startInactiveSpan function in tedious.ts, similar to how it is done in mysql.ts and postgres.ts. This will ensure consistency across database integrations.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/server-utils/src/integrations/tracing-channel/tedious.ts#L143-L147
Potential issue: In `tedious.ts`, the call to `startInactiveSpan` does not include the
`op: 'db'` field in its options. This is inconsistent with other database integrations
like `mysql.ts` and `postgres.ts`, which explicitly set this field. The associated tests
expect the `op` field to be present on the generated spans. Its absence will cause test
failures and may affect how these spans are processed or displayed, as they will be
missing a key piece of contextual information that identifies them as database
operations.


Migrates the tedious integration off the vendored
InstrumentationBaseonto anode:diagnostics_channelsubscriber whose channels orchestrion injects into the library. The OTel path stays as the fallback when orchestrion isn't injected.closes #20766