Uh oh!
There was an error while loading. Please reload this page.
ref(node): Streamline vendored mysql instrumentation - #21568
Merged
Conversation
Contributor
size-limit report 📦
|
Uh oh!
There was an error while loading. Please reload this page.
mydea added a commit
that referenced
this pull request
Jun 24, 2026
…21684) This updates the node-integration-tests for `mysql` package for better test coverage (in preparation of #21568), as well as also fixing some holes in the tests: * Previously, we did not have any MySQL server, which lead to some weird quirks, e.g. spans being marked as failed because no server is found etc. This kind of skewed the results. This PR introduces a minimal, node-written MySQL server that only replies with OK/ERROR, just enough for our tests. * Add tests for connection pooling * Add tests for streamed query errors * Add tests for context stability in streamed queries
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 23da82a. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
mydea
marked this pull request as ready for review
June 26, 2026 09:19
mydea
requested review from
JPeer264 and andreiborza
and removed request for
a teamJune 26, 2026 09:19
andreiborza added a commit
that referenced
this pull request
Jun 26, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
Uh oh!
There was an error while loading. Please reload this page.
andreiborza
approved these changes
Jun 26, 2026
andreiborza added a commit
that referenced
this pull request
Jun 26, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 27, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 27, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 28, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
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>
…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>
Uh oh!
There was an error while loading. Please reload this page.
andreiborza added a commit
that referenced
this pull request
Jun 29, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 29, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 29, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 29, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 30, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 30, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 30, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 30, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 30, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jun 30, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
49 tasks
andreiborza added a commit
that referenced
this pull request
Jul 1, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jul 1, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
andreiborza added a commit
that referenced
this pull request
Jul 2, 2026
Under the SentryTracerProvider, streamed spans carry `sentry.origin` as a first-class attribute including the default `manual` value, whereas the OpenTelemetry SDK path omits the `manual` default. The `mysql` (v1) db spans and the `pg.connect` span set no explicit origin, so they surface as `manual` here. Assert it for now. When those instrumentations are reworked to set an explicit `auto.db.otel.*` origin (e.g. #21568 for mysql), these expectations will be updated to the real origin then.
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.
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