feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0#21548
Merged
Conversation
…strumentation The vendored `@opentelemetry/instrumentation-aws-sdk` had almost no test coverage - only S3 `PutObject` was exercised, leaving DynamoDB, SQS, SNS, Lambda, Kinesis, SecretsManager and StepFunctions (~97% of the service extension code) completely untested. This adds `nock`-based integration tests (mirroring the existing S3 test) covering the span name, op, origin and service-specific attributes for each service the SDK instruments: * S3 - expanded to PutObject, GetObject and an errored GetObject * DynamoDB - PutItem + Query (db.* attributes, op `db`) * SQS - SendMessage + ReceiveMessage (messaging.* attributes, PRODUCER/CONSUMER) * SNS - Publish (messaging.* attributes, topic ARN) * Lambda - Invoke (faas.* attributes) * Kinesis - PutRecord (stream name) * SecretsManager - GetSecretValue (secret ARN) * StepFunctions - StartExecution (state machine ARN) This is step 1 of streamlining the vendored aws-sdk instrumentation - the tests lock in current behavior so the upcoming cleanup and Sentry-API migration can be done safely. Notes: * The new `@aws-sdk/client-*` packages are pinned to `3.1041.0` (matching the existing S3 dep) because newer clients route through `@smithy/core`, which the current instrumentation does not patch. * The Kinesis client is forced onto the HTTP/1 request handler because it defaults to HTTP/2, which `nock` cannot intercept. Addresses step 1 of #20944 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mydea
force-pushed
the
fix/aws-sdk-smithy-core-instrumentation
branch
from
f5a2d59 to
8b34564
Compare
… 3.24.0 `@smithy/core@3.24.0` moved the `Client` class out of `@smithy/smithy-client` into the `@smithy/core/client` bundle and turned `constructStack` into a closed-over local, so the vendored instrumentation - which created spans by wrapping `constructStack` exported from `@smithy/middleware-stack` - silently produced no spans for any AWS service on `@aws-sdk/*` >= 3.1046.0. This backports the upstream fix (open-telemetry/opentelemetry-js-contrib#3530, released in @opentelemetry/instrumentation-aws-sdk@0.74.0): * Patch `Client.prototype.send` in `@smithy/core/dist-cjs/submodules/client/index.js` for `@smithy/core` >= 3.24.0. * From within the `send` patch, patch the live `middlewareStack` instance directly (its `resolve` is the span-creation point) instead of relying on the no-longer-patchable `constructStack` export. * Guard `clone`/`concat` wrapping with `isWrapped` so repeated patching is safe. The aws-integration tests are consolidated into a single scenario that exercises all instrumented services, and run via `createEsmAndCjsTests` + `describe.each` against two dependency sets: * `latest` - the workspace `@aws-sdk/*` (`@smithy/core` >= 3.24.0, the new path) * `v3.1041.0` - aws-sdk 3.1041.0 pinned together with the pre-`@smithy/core` smithy stack via `additionalDependencies`, exercising the old `@smithy/middleware-stack` path Both run the same assertions in ESM and CJS, proving spans are produced on both architectures. Pinning only the client is not enough - `@smithy/smithy-client` must also be pinned < 4.13, otherwise it pulls `@smithy/core` >= 3.24.0 again. Fixes #21546 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mydea
force-pushed
the
fix/aws-sdk-smithy-core-instrumentation
branch
from
8b34564 to
b2ced23
Compare
mydea
changed the base branch from
test/aws-sdk-instrumentation-coverage
to
develop
mydea
changed the title
mydea
changed the title
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
andreiborza
approved these changes
Jun 15, 2026
mydea
force-pushed
the
fix/aws-sdk-smithy-core-instrumentation
branch
from
b2ced23 to
f5d221f
Compare
Contributor
size-limit report 📦
|
mydea
force-pushed
the
fix/aws-sdk-smithy-core-instrumentation
branch
from
f5d221f to
0cf5876
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
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.
The vendored @opentelemetry/instrumentation-aws-sdk had almost no test coverage — only S3 PutObject was exercised, leaving DynamoDB, SQS, SNS, Lambda, Kinesis, SecretsManager and StepFunctions (~97% of the service-extension code) completely untested.
This adds nock-based integration tests (mirroring the existing S3 test) that lock in the current span output (name, op, origin, and service-specific attributes) for every service the SDK instruments:
status: internal_error)op: db,db.*+aws.dynamodb.*)messaging.*, PRODUCER/CONSUMER, message id, batch count)messaging.*, topic ARN)faas.*)This showed that actually we did not instrument newer versions of the AWS SDK. So this PR also vendors a fix for this from the upstream otel instrumentation. Integration tests run for both sets of versions.
@smithy/core@3.24.0moved theClientclass out of@smithy/smithy-clientinto the@smithy/core/clientbundle and turnedconstructStackinto a closed-over local. Our vendored aws-sdk instrumentation creates spans by wrappingconstructStack(exported from@smithy/middleware-stack), so it silently produced no spans for any AWS service on@aws-sdk/*>=3.1046.0. See #21546 for the full root-cause writeup.This backports the upstream fix (open-telemetry/opentelemetry-js-contrib#3530, released in
@opentelemetry/instrumentation-aws-sdk@0.74.0):Client.prototype.sendin@smithy/core/dist-cjs/submodules/client/index.jsfor@smithy/core >= 3.24.0.sendpatch, patch the livemiddlewareStackinstance directly (itsresolveis the span-creation point) rather than the no-longer-patchableconstructStackexport.clone/concatwrapping withisWrappedso repeated patching is safe.Fixes #21546