feat(deps): update deps matching '@opentelemetry/*'

[opentelemetrybot]

Updates all @opentelemetry/* dependencies to latest

[pichlermarc]

Hmm, looks like some tooling error.

[david-luna]

Hmm, looks like some tooling error.

I'm looking at the issue. pg instrumentation work is in #3015

[trentm]

Updated the branch to get the #3017 fix.

[trentm]

Presumably this got a bit further. The unit-test (24) passed this time and didn't the first go round.

[trentm]

All the other unit-test versions failed in test-all-versions of instr-redis (in the v2-v3 tests):

...
   1) redis v2-v3
       #createClient()
         should propagate the current span to event handlers:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/packages/instrumentation-redis/test/v2-v3/redis.test.ts)
      at listOnTimeout (node:internal/timers:581:17)
      at processTimers (node:internal/timers:519:7)

  2) redis v2-v3
       #send_internal_message()
         "before all" hook in "#send_internal_message()":
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/packages/instrumentation-redis/test/v2-v3/redis.test.ts)
      at listOnTimeout (node:internal/timers:581:17)
      at processTimers (node:internal/timers:519:7)

  3) redis v2-v3
       #send_internal_message()
         "after all" hook in "#send_internal_message()":
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/packages/instrumentation-redis/test/v2-v3/redis.test.ts)
      at listOnTimeout (node:internal/timers:581:17)
      at processTimers (node:internal/timers:519:7)
...

As well the unit-test (20) had a second failure, in test-v3 of instr-mongodb:

...

  1) MongoDBInstrumentation-Tracing-v3
       requireParentSpan
         should not create spans without parent span when requireParentSpan is explicitly set to true:

      AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

1 !== 0

      + expected - actual

      -1
      +0
      
      at /home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/packages/instrumentation-mongodb/test/mongodb-v3.test.ts:689:20
      at processTicksAndRejections (node:internal/process/task_queues:95:5)
...

[trentm]

I cannot repro the instr-redis test-all-versions test failures locally.

npm run test-all-versions:with-services-env -w @opentelemetry/instrumentation-redis

# OR
cd packages/instrumentation-redis
npm run test-all-versions:with-services-env

I've created #3019 to try to play with this in CI independent of this PR.

[trentm]

Oh, I can reproduce the instr-redis TAV failures with the deps changes in this PR. My "could not repro" above was just trying on "main" -- falsely assuming David's recent test workflow changes were at fault. Duh.

So the current failures are legitimate test failures for the changes in this PR.

[trentm]

I personally am super-excited to dig into why recent core-repo otel package changes are breaking instr-redis test for this redis release from 2021 and earlier versions.

  '3.1.2': '2021-04-20T22:26:05.946Z',

[trentm]

Well, I feel like this is unhelpful of npm:

[16:39:24 trentm@peach:~/tm/opentelemetry-js-contrib8/packages/instrumentation-redis (git:feat/update-otel-deps)]
% npm install --no-save [email protected]

up to date, audited 2853 packages in 2s

292 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
[16:39:31 trentm@peach:~/tm/opentelemetry-js-contrib8/packages/instrumentation-redis (git:feat/update-otel-deps)]
% npm ls redis
[email protected] /Users/trentm/tm/opentelemetry-js-contrib8
└─┬ @opentelemetry/[email protected] -> ./packages/instrumentation-redis
  └── [email protected]

npm install --no-save [email protected] exits non-zero, but doesn't install [email protected].
Sigh.

... and unsurprisingly the redis test for v2-v3 fail when using redis v5.

[trentm]

^^^ That was with these node/npm versions:

% node --version
v20.19.1

% npm --version
10.8.2

Same thing with node v22.17.1 (npm v10.9.2).

With node v24.6.0 (npm v11.5.1) it works:

% npm install --no-save [email protected]

added 3 packages, removed 6 packages, and audited 2850 packages in 2s

293 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
[16:41:57 trentm@peach:~/tm/opentelemetry-js-contrib8/packages/instrumentation-redis (n:24 git:feat/update-otel-deps)]
% npm ls redis
[email protected] /Users/trentm/tm/opentelemetry-js-contrib8
└─┬ @opentelemetry/[email protected] -> ./packages/instrumentation-redis
  └── [email protected] invalid: "^5.6.0" from packages/instrumentation-redis

npm error code ELSPROBLEMS
npm error invalid: [email protected] /Users/trentm/tm/opentelemetry-js-contrib8/node_modules/redis
npm error A complete log of this run can be found in: /Users/trentm/.npm/_logs/2025-09-04T23_41_59_886Z-debug-0.log

and that'll likely be why unit-test (24) passed.

---

Yuck. We can force install the latest npm in CI... but shouldn't have to live with the situation where running TAV locally is basically useless because you don't know if it's able to install the versions of deps it asks for.

Makes one want to burn npm to the ground. Perhaps looking at pnpm or yarn, though that is a big step... and would, for example, require updating TAV to support using one of those package managers.

[trentm]

npm install --no-save [email protected] --global-style "works", but no way to tell tav to do that.

[github-actions]

This package does not have an assigned component owner and is considered unmaintained. As such this package is in feature-freeze and this PR will be closed with 14 days unless a new owner or a sponsor (a member of @open-telemetry/javascript-approvers) for the feature is found. It is the responsibility of the author to find a sponsor for this feature.
Are you familiar with this package? Consider becoming a component owner.

[Ugzuzg]

I have the fixes for the flaky mongodb and mongoose tests here and here.

[david-luna]

Well, I feel like this is unhelpful of npm:

[16:39:24 trentm@peach:~/tm/opentelemetry-js-contrib8/packages/instrumentation-redis (git:feat/update-otel-deps)]
% npm install --no-save [email protected]

up to date, audited 2853 packages in 2s

292 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
[16:39:31 trentm@peach:~/tm/opentelemetry-js-contrib8/packages/instrumentation-redis (git:feat/update-otel-deps)]
% npm ls redis
[email protected] /Users/trentm/tm/opentelemetry-js-contrib8
└─┬ @opentelemetry/[email protected] -> ./packages/instrumentation-redis
  └── [email protected]

npm install --no-save [email protected] exits non-zero, but doesn't install [email protected]. Sigh.

... and unsurprisingly the redis test for v2-v3 fail when using redis v5.

This run in a different PR succeeded to run test-all-versions with in redis package https://github.com/open-telemetry/opentelemetry-js-contrib/actions/runs/17476483680/job/49637949647?pr=2975 which makes this issue even more strange.

[david-luna]

another example https://github.com/open-telemetry/opentelemetry-js-contrib/actions/runs/17476476112/job/49637930453?pr=3014

[Ugzuzg]

With the patched tav, the only test failures I've seen so far were due to the flaky tests (some connections timing out, etc). None were caused by installation issues yet (well, apart from a new version of @aws-sdk/client-bedrock-runtime getting released yesterday at the same time as the tests were running and then disappearing for a bit and reappearing again).

[trentm]

@david-luna

which makes this issue even more strange.

I think the "npm install doesn't install the thing" depends on the state of the package-lock file (or the existing node_modules/... tree). The package-lock.json changes in this PR are sufficient to tickle this npm install bug for installing particular redis versions.

[david-luna]

I guess this one superseded by #3027

right @pichlermarc ?