ref(node): Streamline vendored mysql instrumentation#21568
Conversation
Streamlines the vendored `@opentelemetry/instrumentation-mysql`, mirroring the already-streamlined `mysql2` sibling: * Migrate span creation from the OpenTelemetry tracer to Sentry's `startInactiveSpan`, and set the `auto.db.otel.mysql` span origin directly. * Remove the connection-pool metrics (`db.client.connections.usage` counter, pool event listeners, `_patchPoolEnd`/`_patchAdd`/`_setPoolCallbacks`, `getPoolNameOld`) - Sentry does not consume OTel metrics. * Remove the OTel semconv-stability dual-emission and keep the default (OLD) attribute set (`db.system`/`db.name`/`db.user`/`db.statement`, `net.peer.name`/`net.peer.port`), which is what the SDK emits today. * Remove the unused `enhancedDatabaseReporting` option (the public `mysqlIntegration()` cannot set it) and its `getDbValues`/`AttributeNames` helpers; `MySQLInstrumentationConfig` collapses to `InstrumentationConfig`. * Remove the `/* eslint-disable */` from the vendored files and make them pass the (type-aware) linter via the shared vendored override. The OTel context plumbing (`trace.setSpan`/`context.with`/`context.bind` and the pool `getConnection` context propagation) is kept as-is to minimize behavior change. No change to emitted spans - the existing mysql integration tests cover the query/callback/stream paths, and a fake-connection smoke test confirms the span op/description/attributes/origin are unchanged. Closes #20738 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
size-limit report 📦
|
…config Per review: don't loosen the shared `.oxlintrc` vendored override for the mysql files; instead resolve the lint findings in the files themselves. * `mysql-types.ts`: replace the inlined `any`s with `unknown` (index signatures, loose `values`/`results`, event-listener args). * `utils.ts`: type `getConfig`'s parameter instead of `any`. * `instrumentation.ts`: keep targeted `oxlint-disable-next-line` comments only where the shimmer-style wrapping genuinely needs `any`/`this`-aliasing, and type the remaining sites (`this: unknown`, `unknown` callback results, the streamed-error cast). Lint is clean (0/0) without the base-config change. Build passes and a fake-connection smoke test confirms the span output is unchanged. Part of #20738 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…origin) The existing mysql scenarios only covered a single `createConnection` with the callback and streamed-success paths. Add coverage for the paths the streamlining touched: * Assert the `auto.db.otel.mysql` span origin (previously unverified). * `createPool` + `pool.query` (covers `_patchCreatePool` / `_patchQuery(pool)`). * A failing streamed query, asserting the span is marked `internal_error` via the stream `error` event handler. Part of #20738 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… context Adds a scenario that starts a span from inside a streamed query's `end` listener and asserts it is parented to the transaction (the context active when the query was issued), not to the query span - covering the `context.bind(parentContext, streamableQuery)` behavior in the instrumentation. Part of #20738 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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 2b3d982. Configure here.
| // this is the callback passed into a query | ||
| // no need to unwrap | ||
| if (!isWrapped(connection.query)) { | ||
| thisPlugin._wrap(connection, 'query', thisPlugin._patchQuery(connection)); |
There was a problem hiding this comment.
Stream queries drop parent context
Medium Severity
For callback-less query calls, the prior instrumentation captured the active context at query start and used OpenTelemetry context.bind on the returned Query so asynchronous error/end listeners (and user code attached via query.on) ran under that parent context, not under the DB span. That bind was removed and only a synchronous withActiveSpan wraps originalQuery, while the captured scope is unused on the stream path. Stream listeners can then run without the transaction scope that was active when the query was issued, so spans started inside those listeners may parent to the wrong span or lose the intended trace hierarchy.
Reviewed by Cursor Bugbot for commit 2b3d982. Configure here.


Streamlines the vendored
@opentelemetry/instrumentation-mysql(#20738), mirroring the already-streamlinedmysql2sibling.Changes
startInactiveSpan, with theauto.db.otel.mysqlorigin set directly (new — matches mysql2; the existing tests don't assert origin).db.client.connections.usagecounter, pool event listeners,_patchPoolEnd/_patchAdd/_setPoolCallbacks,getPoolNameOld) — Sentry doesn't consume OTel metrics.db.system/db.name/db.user/db.statement,net.peer.name/net.peer.port), which is what's emitted today.enhancedDatabaseReportingoption (the publicmysqlIntegration()can't set it) +getDbValues/AttributeNames;MySQLInstrumentationConfigcollapses toInstrumentationConfig(sotypes.ts/AttributeNames.tsare deleted)./* eslint-disable */from all vendored files; they pass the type-aware linter via the shared vendored override.The OTel context plumbing (
trace.setSpan/context.with/context.bind+ the poolgetConnectioncontext propagation) is intentionally kept to minimize behavior change.Verification
op: 'db', description'SELECT 1 + 1 AS solution'(fromdb.statement),origin: 'auto.db.otel.mysql',db.system/net.peer.name/net.peer.port/db.useras asserted by the tests.Closes #20738