Skip to content

feat!: require OpenTelemetry JS SDK 3 - #36

Merged
RomainLanz merged 4 commits into
mainfrom
feat/otel-sdk-3
Nov 12, 2026
Merged

RomainLanz merged 4 commits into
mainfrom
feat/otel-sdk-3

Conversation

@Julien-R44

Copy link
Copy Markdown
Member

Moves the OpenTelemetry instrumentation to OpenTelemetry JS SDK 3 and fixes three bugs found while testing it against a real AdonisJS application.

SDK 3

SDK 3 packages declare an @opentelemetry/api peer of >=1.10.0 <1.11.0, and @opentelemetry/core 2 requires api <1.10.0, so one release cannot support both SDKs. The optional peers move to api ^1.10.0, core ^3.0.0 and instrumentation >=0.300.0 <0.400.0. The instrumentation code needed no change; the tests move from the removed sdk-trace-base to sdk-trace.

This is a breaking change: applications on SDK 2 stay on 0.9.x. @adonisjs/queue depends on @boringnode/queue ^0.9.0 and needs a release with the new range.

Fixes

  • Dedup: a dispatch skipped by .dedup() reported a job ID that never exists in the queue. The PRODUCER span now reports the ID of the existing job and messaging.job.dedup_outcome.
  • disable(): the execution wrapper kept starting CONSUMER spans that nothing ended, and their map grew with each job. The wrapper now runs the job without a span when the instrumentation is not subscribed.
  • Scope version: spans carried a hardcoded 0.1.0; they now carry the package version.

Verification

  • Build, typecheck, lint, format, and the full suite against Redis, Postgres and MySQL pass.
  • End to end in an AdonisJS 7 app with the SDK 3 branch of @adonisjs/otel and Jaeger, in dev and from node ace build: one copy each of api 1.10.0, core 3.1.1 and instrumentation 0.301.1. HTTP dispatch, nested dispatch, batch, delayed, retries, permanent failure, timeout, dedup, sync and database adapters, scheduled jobs, 10 concurrent jobs, and both link and parent modes produce correctly parented and linked spans, with no span from worker polling.

SDK 3 packages declare an `@opentelemetry/api` peer of `>=1.10.0 <1.11.0`
while `@opentelemetry/core` 2 requires `api <1.10.0`, so an application
cannot install SDK 2 and SDK 3 packages side by side. The optional peers
only accepted SDK 2, which blocked every application moving to SDK 3.

The peers now require `api` ^1.10.0, `core` ^3.0.0 and `instrumentation`
>=0.300.0 <0.400.0. The instrumentation code needed no change. The tests
move from the removed `@opentelemetry/sdk-trace-base` to
`@opentelemetry/sdk-trace`.

BREAKING CHANGE: the OpenTelemetry instrumentation requires OpenTelemetry
JS SDK 3. Applications on SDK 2 should stay on 0.9.x.
…rsion

The instrumentation passed a hardcoded '0.1.0' to InstrumentationBase, so
every span carried a scope version unrelated to the installed package.
Read the name and version from package.json instead.
A dispatch with `.dedup()` that did not add a job still produced a
PRODUCER span with the ID generated for the discarded job, an ID that
never exists in the queue, and nothing told it apart from a dispatch
that added one. The caller, meanwhile, gets the ID of the existing job.

The dispatch message now carries the ID of the job that holds the dedup
key, and the PRODUCER span reports it as `messaging.message.id` with the
outcome in `messaging.job.dedup_outcome`.
QueueManager keeps the execution wrapper it received from the patched
init(), so after disable() it still started a CONSUMER span for every
job. The execute subscription that ends those spans was gone: they never
ended and the map that tracks them grew with each execution.

The wrapper now runs the job without a span when the instrumentation is
not subscribed.
@RomainLanz
RomainLanz merged commit c6eff33 into main Nov 12, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants