Summary
The vendored @opentelemetry/instrumentation-aws-sdk (AwsInstrumentation, used by awsIntegration in @sentry/aws-serverless) silently produces no spans for applications using @aws-sdk/* client packages at version 3.1046.0 or newer (published 2026-05-14 onwards). All AWS service spans (S3, DynamoDB, SQS, SNS, Lambda, Kinesis, etc.) are missing — there is no error, the instrumentation simply never attaches.
Root cause
AwsInstrumentation creates spans by patching the AWS SDK v3 middleware plumbing. Its init() registers patches for:
@aws-sdk/middleware-stack and @smithy/middleware-stack → wraps constructStack, which wraps the stack's resolve to start the span (this is the span-creation entry point)
@aws-sdk/smithy-client and @smithy/smithy-client → wraps Client.prototype.send to attach the client config (used for the region attribute)
Starting with @aws-sdk/client-*@3.1046.0, AWS SDK JS v3 migrated to schema-based serialization and consolidated the middleware stack and smithy client into @smithy/core. The clients no longer depend on (or require) @smithy/middleware-stack or @smithy/smithy-client.
Because the modules the instrumentation hooks are no longer in the require graph, the require-in-the-middle hooks never fire, constructStack is never wrapped, and no spans are created.
When it was introduced
Bisecting @aws-sdk/client-s3 dependency metadata:
| Version |
@smithy/middleware-stack |
@smithy/smithy-client |
@smithy/core |
Instrumented? |
3.1045.0 (2026-05-07) |
^4.2.14 |
^4.12.13 |
^3.23.17 |
✅ yes |
3.1046.0 (2026-05-14) |
— (removed) |
— (removed) |
^3.24.1 |
❌ no |
So the regression is in the SDK side and affects @aws-sdk/* >= 3.1046.0, correlating with @smithy/core >= 3.24.x.
Reproduction
const Sentry = require('@sentry/aws-serverless');
Sentry.init({ dsn: '...', tracesSampleRate: 1.0 });
const { DynamoDBClient, PutItemCommand } = require('@aws-sdk/client-dynamodb'); // >= 3.1046.0
const client = new DynamoDBClient({ region: 'us-east-1' });
await Sentry.startSpan({ name: 'tx' }, async () => {
await client.send(new PutItemCommand({ TableName: 't', Item: { id: { S: 'x' } } }));
});
// => the transaction contains NO `DynamoDB.PutItem` span
With @aws-sdk/*@3.1045.0 (or 3.1041.0) the same code produces the expected span. Verified locally while writing the integration tests in #21543 — pinning the test clients to 3.1041.0 produces spans; 3.1068.0 produces none. Only @smithy/core, @smithy/types, @smithy/signature-v4, and @smithy/node-http-handler are loaded for the newer clients (none of which the instrumentation patches).
Suggested fix
Add patching for the new @smithy/core schema-client mechanism — i.e. wrap constructStack / the middleware-resolve path wherever it now lives inside @smithy/core (and confirm how the client config is now exposed for the region attribute). This needs investigation into the new @smithy/core API surface.
Worth also checking whether upstream @opentelemetry/instrumentation-aws-sdk has already addressed this, so we can mirror their approach when we streamline the vendored instrumentation.
Notes
Summary
The vendored
@opentelemetry/instrumentation-aws-sdk(AwsInstrumentation, used byawsIntegrationin@sentry/aws-serverless) silently produces no spans for applications using@aws-sdk/*client packages at version3.1046.0or newer (published 2026-05-14 onwards). All AWS service spans (S3, DynamoDB, SQS, SNS, Lambda, Kinesis, etc.) are missing — there is no error, the instrumentation simply never attaches.Root cause
AwsInstrumentationcreates spans by patching the AWS SDK v3 middleware plumbing. Itsinit()registers patches for:@aws-sdk/middleware-stackand@smithy/middleware-stack→ wrapsconstructStack, which wraps the stack'sresolveto start the span (this is the span-creation entry point)@aws-sdk/smithy-clientand@smithy/smithy-client→ wrapsClient.prototype.sendto attach the client config (used for the region attribute)Starting with
@aws-sdk/client-*@3.1046.0, AWS SDK JS v3 migrated to schema-based serialization and consolidated the middleware stack and smithy client into@smithy/core. The clients no longer depend on (orrequire)@smithy/middleware-stackor@smithy/smithy-client.Because the modules the instrumentation hooks are no longer in the require graph, the
require-in-the-middlehooks never fire,constructStackis never wrapped, and no spans are created.When it was introduced
Bisecting
@aws-sdk/client-s3dependency metadata:@smithy/middleware-stack@smithy/smithy-client@smithy/core3.1045.0(2026-05-07)^4.2.14^4.12.13^3.23.173.1046.0(2026-05-14)^3.24.1So the regression is in the SDK side and affects
@aws-sdk/*>=3.1046.0, correlating with@smithy/core>=3.24.x.Reproduction
With
@aws-sdk/*@3.1045.0(or3.1041.0) the same code produces the expected span. Verified locally while writing the integration tests in #21543 — pinning the test clients to3.1041.0produces spans;3.1068.0produces none. Only@smithy/core,@smithy/types,@smithy/signature-v4, and@smithy/node-http-handlerare loaded for the newer clients (none of which the instrumentation patches).Suggested fix
Add patching for the new
@smithy/coreschema-client mechanism — i.e. wrapconstructStack/ the middleware-resolve path wherever it now lives inside@smithy/core(and confirm how the client config is now exposed for the region attribute). This needs investigation into the new@smithy/coreAPI surface.Worth also checking whether upstream
@opentelemetry/instrumentation-aws-sdkhas already addressed this, so we can mirror their approach when we streamline the vendored instrumentation.Notes
@aws-sdk/client-*to3.1041.0— the newer clients are not instrumented, so tests against them would assert against empty span lists.@opentelemetry/instrumentation-aws-sdk#20944 (streamlining the vendored aws-sdk instrumentation).