Skip to content

feat: introducing w3c tracing headers propagation#8147

Closed
darklight3it wants to merge 1 commit into
aws:mainfrom
darklight3it:feat/support-propagation-of-w3c-headers
Closed

feat: introducing w3c tracing headers propagation#8147
darklight3it wants to merge 1 commit into
aws:mainfrom
darklight3it:feat/support-propagation-of-w3c-headers

Conversation

@darklight3it

@darklight3it darklight3it commented Jul 2, 2026

Copy link
Copy Markdown

Issue

N/A — W3C trace context propagation

Description

Adds a build-step middleware that propagates W3C trace context headers (traceparent, tracestate, baggage) from the Lambda InvokeStore onto outbound AWS SDK requests.

Why: When a Lambda function receives a request with trace context, downstream calls made via the AWS SDK should carry that context forward. This enables distributed tracing across service boundaries on the AWS SDK.

How it works:

  • The middleware reads trace context from @aws/lambda-invoke-store (which the Lambda runtime populates per-invocation from inbound headers)
  • If traceparent is present and the outgoing request doesn't already have one, it injects traceparent, tracestate, and baggage headers
  • Existing trace headers are respected (never overwritten) and normalized to lowercase
  • Browser and React Native get no-op implementations (InvokeStore is Node-only)

Design decisions:

  • Registered as a plugin (getTraceContextPropagationPlugin) — not auto-added to generated clients.
  • traceparent is the gate: tracestate and baggage are only propagated when traceparent is present (per W3C spec).
  • InvokeStore.getInstanceAsync() is memoized at module level — subsequent calls on the hot path just await a resolved promise.

Testing

  • 7 unit tests covering: full propagation, partial headers, missing traceparent, no InvokeStore context, existing headers preserved, case normalization, non-HTTP request no-op
  • 1 integration test exercising a real S3 client middleware stack with requireRequestsFrom (no network calls)
  • All tests pass locally. Fork CI cannot authenticate with upstream's AWS OIDC role (expected for fork PRs).

Checklist

  • If the PR is a feature, add integration tests (*.integ.spec.ts) or E2E tests.
    • It's not a feature.
  • My E2E tests are resilient to concurrent i/o.
    • I didn't write any E2E tests.
  • I added access level annotations e.g. @public, @internal tags and enabled doc generation on the package. Remember that access level annotations go below the description, not above.
    • I didn't add any public functions.
  • Streams - how do they work?? My WebStream readers/locks are properly lifecycled. Node.js stream backpressure is handled. Error handling.
    • No streams here.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@darklight3it
darklight3it requested a review from a team as a code owner July 2, 2026 19:01
@darklight3it
darklight3it force-pushed the feat/support-propagation-of-w3c-headers branch from 5f22f9f to 8682fc1 Compare July 2, 2026 21:23
@kuhe

kuhe commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

moved to #8156

@kuhe kuhe closed this Jul 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants