[opentelemetry-instrumentation-aws-lambda] Context handling does not follow Semantic Conventions for Instrumenting AWS Lambda

[ithompson-gp]

Issue

According to official trace semantic conventions for Instrumenting AWS Lambda, given an AWS Lambda - generated - sampled trace context (_X_AMZN_TRACE_ID), this context must be supplied - via instrumentation - as a Span Link when initialising a Span encapsulating the - wrapped - function handler being invoked.

This expected functionality is explained in detail in the same semantic conventions doc in the AWS X-Ray Environment Span Link section.

Which plugin?

• opentelemetry-instrumentation-aws-lambda

Where in code?

• instrumentation.ts#L199-L213

Actions?

Given the inconsistencies between Lambda trace conventions and code being shipped, is there a timeline for solving these inconsistencies?

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

[srprash]

Hi @ithompson-gp
There's already an open PR regarding this FaaS specification: #1411

There is ongoing discussions on accepting the PR since it is a breaking change for Lambda customers.

[ithompson-gp]

@srprash Has there been any move to merge this (#1411)?
As an end-user, we would like conventions to be respected, and move forward with developing Span Link as a means to represent causal relationships in an async EDA.
This is a true blocker to any FaaS adoption of OpenTelemetry (lack of Span Link in end systems and the development on the OTEL side to integrate with Messaging SIG)