chore(deps): bump @opentelemetry/instrumentation-aws-sdk from 0.59.0 to 0.76.0 - #1288
Conversation
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
Coverage Report for CI Build 31643544349Coverage increased (+19.6%) to 81.025%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM. Standard automated dependency bump; the inline nit about the nested 0.75.0 shadow copy is informational and doesn't block merging.
Extended reasoning...
Overview
This is a Dependabot PR that bumps @opentelemetry/instrumentation-aws-sdk from ^0.59.0 to ^0.76.0 in package.json, with the corresponding package-lock.json regeneration. No application source code is touched.
Security risks
None. This is a transitive OpenTelemetry instrumentation package used only for AWS SDK tracing spans; it has no auth, crypto, or data-handling logic in this codebase. The lockfile diff is a mechanical, tool-generated update.
Level of scrutiny
Low. This is the class of PR (automated, mechanical dependency bump, lockfile-only) that fits the approval bar for straightforward changes. The one inline finding is a nit noting the bump doesn't actually take effect at runtime due to a nested dependency shadow from @opentelemetry/auto-instrumentations-node still requiring ^0.75.0 — it's a no-op, not a regression, so it doesn't change the risk profile of merging.
Other factors
No behavior changes, no tests needed beyond what CI already covers for dependency installs. Nothing in the PR timeline indicates unresolved discussion.
| "@opentelemetry/exporter-prometheus": "^0.221.0", | ||
| "@opentelemetry/host-metrics": "^0.38.3", | ||
| "@opentelemetry/instrumentation-aws-sdk": "^0.59.0", | ||
| "@opentelemetry/instrumentation-aws-sdk": "^0.76.0", |
There was a problem hiding this comment.
🟡 This bumps the direct @opentelemetry/instrumentation-aws-sdk dependency to ^0.76.0, but the sole consumer, getNodeAutoInstrumentations() in src/internal/monitoring/otel-tracing.ts, comes from @opentelemetry/auto-instrumentations-node, which still requires ^0.75.0 (unchanged by this PR). Since 0.76.0 doesn't satisfy that caret range, npm keeps a nested 0.75.0 copy that Node actually resolves at runtime, so this bump has no effect on the instrumentation that runs in production — it's harmless to merge, but doesn't achieve the intended upgrade.
Extended reasoning...
This PR bumps the top-level @opentelemetry/instrumentation-aws-sdk dependency in package.json (and the corresponding top-level entry in package-lock.json) from ^0.59.0 to ^0.76.0. The problem is that nothing in src/ imports this package directly — grepping the codebase confirms the only reference is a config key string passed to getNodeAutoInstrumentations() in src/internal/monitoring/otel-tracing.ts:187, and that function is exported by the separate @opentelemetry/auto-instrumentations-node package.
@opentelemetry/auto-instrumentations-node (currently ^0.78.0, unchanged by this PR) declares its own dependency on @opentelemetry/instrumentation-aws-sdk pinned to ^0.75.0 (see package-lock.json line 3938). Because caret ranges on 0.x.y versions only permit patch-level bumps, 0.76.0 does not satisfy ^0.75.0. npm therefore cannot dedupe the two requirements into a single copy, and the lockfile shows a nested, shadowed install at node_modules/@opentelemetry/auto-instrumentations-node/node_modules/@opentelemetry/instrumentation-aws-sdk still pinned at 0.75.0, alongside the bumped top-level copy at 0.76.0.
Node's module resolution algorithm means that when auto-instrumentations-node internally requires @opentelemetry/instrumentation-aws-sdk, it resolves to its own nested node_modules copy (0.75.0) before ever reaching the top-level one. Since getNodeAutoInstrumentations() is the only place this instrumentation gets loaded in this codebase, the top-level 0.76.0 copy is never actually required by any code path — it is dead weight in the dependency tree.
Step-by-step proof:
otel-tracing.tsimportsgetNodeAutoInstrumentationsfrom@opentelemetry/auto-instrumentations-node, not from@opentelemetry/instrumentation-aws-sdkdirectly.getNodeAutoInstrumentations()internally does the equivalent ofrequire('@opentelemetry/instrumentation-aws-sdk')from insideauto-instrumentations-node's own file location.- Node resolution walks up from
node_modules/@opentelemetry/auto-instrumentations-node/and findsnode_modules/@opentelemetry/auto-instrumentations-node/node_modules/@opentelemetry/instrumentation-aws-sdk(version 0.75.0) before reaching the top-levelnode_modules/@opentelemetry/instrumentation-aws-sdk(version 0.76.0). - Therefore the AWS SDK instrumentation actually loaded and executed at runtime is 0.75.0, regardless of what the top-level
package.json/package-lock.jsondeclare. - None of the changes shipped in 0.76.0 (the smithy/core >=3.24.0 middlewareStack patch, the semantic-convention attribute changes) take effect.
Impact-wise, this is not a functional regression: nothing crashes, no behavior changes, and the AWS SDK instrumentation continues running at the same 0.75.0 version it ran at before this PR (the direct dependency was already mismatched with auto-instrumentations-node's ^0.75.0 requirement back when it was pinned at ^0.59.0, so the nested-copy/shadowing situation is pre-existing in shape, even though the specific version bump here is new). The practical consequence is just that this particular Dependabot bump is a no-op for the code that actually runs — it changes a version number nobody loads.
To actually get 0.76.0 running, either the direct dependency should be dropped (since it is unused outside of auto-instrumentations-node) or auto-instrumentations-node itself needs to be updated to a version that requires @opentelemetry/instrumentation-aws-sdk ^0.76.0 or later, so npm can dedupe to a single top-level copy. Given this is a routine automated dependency bump PR with no code changes, this is worth flagging to the author as an informational note rather than blocking the merge — nothing breaks by merging as-is.
d2b8c41 to
d774942
Compare
Bumps [@opentelemetry/instrumentation-aws-sdk](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/HEAD/packages/instrumentation-aws-sdk) from 0.59.0 to 0.76.0. - [Release notes](https://github.com/open-telemetry/opentelemetry-js-contrib/releases) - [Changelog](https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/packages/instrumentation-aws-sdk/CHANGELOG.md) - [Commits](https://github.com/open-telemetry/opentelemetry-js-contrib/commits/instrumentation-aws-sdk-v0.76.0/packages/instrumentation-aws-sdk) --- updated-dependencies: - dependency-name: "@opentelemetry/instrumentation-aws-sdk" dependency-version: 0.76.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
d774942 to
08f9a5d
Compare
1 participant
Bumps @opentelemetry/instrumentation-aws-sdk from 0.59.0 to 0.76.0.
Release notes
Sourced from @opentelemetry/instrumentation-aws-sdk's releases.
... (truncated)
Changelog
Sourced from @opentelemetry/instrumentation-aws-sdk's changelog.
... (truncated)
Commits
27e172achore: release main (#3596)466d5defeat(deps): update deps matching '@opentelemetry/*' (#3629)b7efd7bchore(*): migrate to sdk-trace (#3599)5b7dd0efeat!: only emit stable http, network and database attributes (#3585)8d7daeachore: release main (#3568)6dfb532feat(deps): update deps matching '@opentelemetry/*' (#3593)4e52a90chore: release main (#3524)bd569b5feat(deps): update deps matching '@opentelemetry/*' (#3567)e4e61fcfix(instrumentation-aws-sdk): patch middlewareStack via Client.send for@smit...15ef750chore: release main (#3508)Maintainer changes
This version was pushed to npm by GitHub Actions, a new releaser for
@opentelemetry/instrumentation-aws-sdksince your current version.