test(aws-serverless): Add integration coverage for aws-sdk service instrumentation by mydea · Pull Request #21543 · getsentry/sentry-javascript

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

mydea · 2026-06-15T12:52:42Z

Summary

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:

S3 — expanded to PutObject, GetObject, and an errored GetObject (status: internal_error)
DynamoDB — PutItem + Query (op: db, db.* + aws.dynamodb.*)
SQS — SendMessage + ReceiveMessage (messaging.*, PRODUCER/CONSUMER, message id, batch count)
SNS — Publish (messaging.*, topic ARN)
Lambda — Invoke (faas.*)
Kinesis — PutRecord (stream name)
SecretsManager — GetSecretValue (secret ARN)
StepFunctions — StartExecution (state machine ARN)

This is step 1 of streamlining the vendored aws-sdk instrumentation — establishing a safety net so the subsequent unused-code cleanup, lint fixes, and Sentry-API migration (steps 2–4) can be done with confidence.

Notes for reviewers

The new @aws-sdk/client-* packages are pinned to 3.1041.0 (matching the existing S3 dep). Newer clients route their middleware through @smithy/core, which the current instrumentation does not patch, so they aren't instrumented at all — see the follow-up issue for details. Pinning keeps the tests exercising the code paths the instrumentation actually supports today.
The Kinesis client is forced onto the HTTP/1 request handler (NodeHttpHandler) because it defaults to HTTP/2, which nock cannot intercept (it was otherwise silently reaching real AWS).

Addresses step 1 of #20944

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 4dfe534. Configure here.}

…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 · 2026-06-15T13:34:24Z

Replaced by #21548

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

cursorBot reviewed Jun 15, 2026
View reviewed changes

Comment threaddev-packages/node-integration-tests/suites/aws-serverless/aws-integration/dynamodb/scenario.js

mydea mentioned this pull request Jun 15, 2026
Ensure AWS SDK instrumentation works >= 3.1046.0 #21546
Closed

mydea force-pushed the test/aws-sdk-instrumentation-coverage branch from 4dfe534 to 4e7eb9aCompare June 15, 2026 12:56

dedupe deps
ec34411

mydea marked this pull request as ready for review June 15, 2026 13:03

mydea requested a review from a team as a code owner June 15, 2026 13:03

mydea requested review from JPeer264 and andreiborza and removed request for a teamJune 15, 2026 13:03

mydea mentioned this pull request Jun 15, 2026
feat(aws-serverless): Instrument aws-sdk clients >= 3.1046.0 #21548
Merged

mydea closed this Jun 15, 2026

JPeer264 deleted the test/aws-sdk-instrumentation-coverage branch June 15, 2026 16:09

Uh oh!

Uh oh!

Conversation

mydea commented Jun 15, 2026

Summary

Notes for reviewers

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mydea commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

mydea commented Jun 15, 2026

Summary

Notes for reviewers

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mydea commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

mydea commented Jun 15, 2026

Summary

Notes for reviewers

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mydea commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

mydea commented Jun 15, 2026

Summary

Notes for reviewers

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mydea commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects