Widen the @opentelemetry/api version bound - #1496
Open
unflxw wants to merge 6 commits into
Open
Conversation
This declaration stood in for a DOM type that the `undici` typings bundled with `@types/node` referred to, which this project does not pull in because its `lib` is set to `es2018`. Those typings no longer refer to it, so the declaration is only a stand-in for nothing. Leaving it in place breaks the build outright from `@types/node` version 25 onwards, because that version declares `BlobPropertyBag` itself and TypeScript reports the two declarations as a conflict. That went unnoticed because the committed `package-lock.json` holds `@types/node` at version 22, so only an install that resolves versions afresh runs into it.
|
Hi @unflxw, We've found some issues with your Pull Request.
|
unflxw
force-pushed
the
otel-relax-api-bound
branch
3 times, most recently
from
August 21, 2026 10:08
f4dd23a to
ba37c49
Compare
Version 3.7.0 set out to stop propagating the trace context, because two applications that both report to AppSignal would join the same trace and the second one's data would be reported against the first one's application. It kept propagating it anyway, for a year. The pull request that did this first disabled every propagator, which was reviewed and agreed. A later commit on the same branch added propagators back, to keep baggage working for customers who use it, and took the `OTEL_PROPAGATORS` factory map in `@opentelemetry/sdk-node` for the list of defaults. That map is the set of propagators a user can name in that environment variable. The defaults are the W3C trace context and baggage propagators, so "the defaults without trace context" became baggage plus the two B3 propagators, and the B3 ones went on sending the trace context in `b3` and `x-b3-*` headers. Keep the part that was deliberate, which is baggage, and drop the part that was not. This costs the span link between a BullMQ publish and the job that processes it, because that link travels through the propagators. The agent does not read span links, so nothing reported to AppSignal changes. The instrumentation's `useProducerSpanAsConsumerParent` option would stop working, but it is off by default and we do not turn it on.
The `express-redis` and `express-rabbitmq` apps are the only test apps whose own code creates spans, so they are the only ones that have to declare `@opentelemetry/api` themselves: `npm link` does not make the integration's copy available to them the way a normal install would. Their bound had been left at version 1.6, which the integration stopped supporting in 2024. Both apps therefore installed one copy of the API for themselves and resolved a second one inside the linked integration. Their custom spans still arrived, but only because an older copy of the API is allowed to read a global registered by a newer one. Had the two versions been the other way around, the apps would have reported no custom spans at all and both suites would have failed with no indication of why.
Two copies of `@opentelemetry/api` in one project make the integration report nothing, without saying so. The API keeps its global tracer provider on `globalThis` and a copy only reads that global when its own version is compatible with the version that wrote it, so the copy that loses the comparison receives a tracer that discards every span. Nothing is logged, so no test fails and no user-visible error appears. Whether that happens is decided by npm's resolution, which depends on the version bounds in `package.json` and on what else the application has installed. It is not visible in the source, so a check is the only way to hold it. The check installs the packed package into a throwaway project with an empty npm cache. Both parts matter. Our own `node_modules` is not what a customer resolves, because `npm link` and our `package-lock.json` both change the answer. A populated cache can serve a resolution that a fresh install would not pick. Copies of other OpenTelemetry packages are reported but do not fail the check. The tree currently holds several, and they are wasteful rather than broken: the API package is the only one whose copies share state through a version-checked global.
Dependabot defaults to widening a range for a library, so it turned the `@opentelemetry/sdk-node` bound from `>= 0.213.0 < 0.214.0` into `>= 0.213.0 < 0.219.0`. That is the opposite of what these bounds are for. They are narrow so that the OpenTelemetry packages released together each resolve to a single version, and a widened bound lets npm resolve a different version of `@opentelemetry/core` for `sdk-node` than for the rest of the tree, which is what happened. Group the OpenTelemetry packages too. They are only correct as a set, so one update covering all of them is reviewable in a way that a pull request per package is not.
Of all the OpenTelemetry bounds this package declares, this is the one that should not be narrow. Every OpenTelemetry package depends on the API as a peer dependency, so a wide bound is what allows npm to resolve a single copy shared with the application. A narrow one is what forces a second copy: when an application resolves a minor version this package excludes, npm satisfies our bound by nesting an older copy inside `@appsignal/nodejs`, and the API then hands out a tracer that does nothing to whichever side loses its version comparison. Right now the bound happens to sit on the newest minor version, so it causes no harm. It becomes harmful as soon as a newer minor version is released and applications start resolving it. The lower bound stays at 1.9.0. Some of the instrumentation packages require at least that version.
unflxw
force-pushed
the
otel-relax-api-bound
branch
from
August 21, 2026 10:36
ba37c49 to
a771471
Compare
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Depends on #1495 and should be merged after it.
Of all the OpenTelemetry bounds this package declares, this is the one
that should not be narrow. Every OpenTelemetry package depends on the
API as a peer dependency, so a wide bound is what allows npm to resolve
a single copy shared with the application. A narrow one is what forces a
second copy: when an application resolves a minor version this package
excludes, npm satisfies our bound by nesting an older copy inside
@appsignal/nodejs, and the API then hands out a tracer that doesnothing to whichever side loses its version comparison.
Right now the bound happens to sit on the newest minor version, so it
causes no harm. It becomes harmful as soon as a newer minor version is
released and applications start resolving it.
The lower bound stays at 1.9.0. Some of the instrumentation packages
require at least that version.