[opentelemetry-instrumentation-aws-lambda] Incorrectly uses trace from _X_AMZN_TRACE_ID instead of `traceparent` header

I think this issue may already be resolved (and not yet released), but wanted to validate that there's no other workaround other than waiting for the release train.

Describe your environment

We have two Lambda functions (ClientLambda and ServerLambda) that both use Python 3.8 and reference Lambda Layer arn:aws:lambda:us-east-1:901920570463:layer:aws-otel-python38-amd64-ver-1-9-1:1.

The ClientLambda is invoked from an API Gateway and the ServerLambda is invoked from an ALB. The ServerLambda is either invoked by the ClientLambda or directly via end users.

Steps to reproduce

When the ClientLambda invokes the ServerLambda, the ClientLambda successfully sets the traceparent header on the outgoing request, e.g., 00-TraceId-SpanId-01. I've confirmed that the ServerLambda also receives the traceparent with the same values. However, the ServerLambda creates its initial span with a parentId extracted from the _X_AMZN_TRACE_ID environment variable instead of the traceparent.

When the ServerLambda is directly invoked via end users, we correctly see trace and span properties populate correctly. These requests come through with an Amazon Trace Id similar to the following: Root=1-TraceId;Parent=SpanId;Sampled=0. I believe this is since the opentelemetry-instrumentation-aws-lambda skips extraction from _X_AMZN_TRACE_ID when Sampled = false.

What is the expected behavior?

The ServerLambda function correctly respects the traceparent header if it exists (or provides a way to bypass trace context extraction from the _X_AMZN_TRACE_ID environment variable.

What is the actual behavior?
See Steps to Reproduce above.

Additional context

I think this has now been handled via a OTEL_LAMBDA_DISABLE_AWS_CONTEXT_PROPAGATION environment variable in the most recent opentelemtry-instrumentation-aws-lambda pushed to main.

Two questions:

• What is the release cadence for this library (and perhaps also the cycle time for it to be included in an updated Lambda Layer)?
• Are there are other workarounds in the meantime that I should evaluate or consider?

References

May relate to some of the following issues:

1. [Python] Tracecontext OTEL propagator config generates an additional X-Ray span
2. [Nodejs] AWS auto-instrumentation doesn't propagate parent trace.id and span.id properly

Start by reviewing opentelemetry-instrumentation-aws-lambda/src/opentelemetry/instrumentation/aws_lambda/init.py at the referenced extraction logic around lines 174-187 and the OTEL_LAMBDA_DISABLE_AWS_CONTEXT_PROPAGATION handling around lines 416-424. Verify whether the fix is present in a released version and whether the referenced Lambda Layer includes it; done means confirming the available release or documenting the remaining workaround.