X-Ray is the same for all runtimes

[rackerWard]

What is the reason the FaaS/aws-lambda has statement that Java should parse an OTEL context first? Why is the Java runtime being treated differently from other runtimes? I think this is a mistake to ignore X-Ray trace context in AWS Lambda.

Note: When instrumenting a Java AWS Lambda, instrumentation SHOULD first try to parse an OpenTelemetry Context out of the system property com.amazonaws.xray.traceHeader using the AWS X-Ray Propagator before checking and attempting to parse the environment variable above.

The a runtime is given the X-Ray trace context via the `/next' response's HTTP header "Lambda-Runtime-Trace-Id" and writes that into the "_X_AMZN_TRACE_ID" environment variable. The only time an OTEL context would be carried in the event payload is

1. The AWS Service triggering the Lambda does not support X-Ray and the event is an envelope data structure having metadata and payload.
2. The client calling AWS Service triggering the Lambda does not support sending the X-Ray trace header; the service is likely API Gateway HTTP. API Gateway Rest Proxy and non-Proxy may require the request template to pass the event with the trace. This requires the handler's event to be an envelope.

API Gateway REST should use X-Ray trace propagation to invoke the AWS Lambda. I don't know if it is possible to convert in a request header a W3C trace header into an X-Ray trace header that API Gateway REST would understand and inject into its Lambda invoke request.

Note: AWS is hopefully going to address Distributed Tracing trace header interoperability!!!!

[trask]

cc @tylerbenson @rapphil

[tylerbenson]

This has been a contentious topic for the past year in the FAAS SIG. You can see the latest iteration of the spec here:
#354. The quick summary: X-Ray propagation is not the problem, but rather sending spans to different backends within a trace is problematic because it results in broken traces.

As for the question why Java is treated differently, I suggest reviewing open-telemetry/opentelemetry-java-instrumentation#7579, open-telemetry/opentelemetry-java-instrumentation#8368, and #27.

[joaopgrassi]

Hi @rackerWard did you had time to follow up on @tylerbenson's reply? If you don't need further things, I will close this issue, as discussion is already happening somewhere else.