AWS Lambda Semantic conventions spec does not provide mechanism for properly propagating context using SQS

[rapphil]

Describe the bug
There exists OTel semantic conventions that define how to represent information related to spans representing the processing of SQS events in AWS Lambda.

As of now, there is no way to properly trace events that happens asynchronously in set of services that communicate using SQS messages. Every lambda invocation will create a new trace context (new trace id) for the SQS Event. If we have xray sampling enabled, that means that each hop in this set of services will have the probability of emitting a new trace or not emitting it. This creates a problem because you will not have the full path of events.

Customers could work around this limitation by using specific xray sampling rules for each hop in the chain of services, but this is not ideal and represents a mismatch with the behavior observed in synchronous http lambda invocations.

What did you expect to see?
We should provide alternatives for customers to use the parent context propagated in the message instead of creating a new trace context on every lambda invocation for an SQS Event.

Additional context

• Lambda events can contain batches of messages https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html
• Context is propagated in SQS in the message, not in the SQS Event, meaning that you can have multiple messages, each with a different trace context, in the same SQS Event. https://docs.aws.amazon.com/xray/latest/devguide/xray-services-sqs.html#xray-services-sqs-retrieving
• Related issue: aws-sdk SQS propagation open-telemetry/opentelemetry-java-instrumentation#5167

[rapphil]

Right now we don't have a good solution that is originated from the spec/standardized. In fact, there is also this upstream issue open-telemetry/semantic-conventions#1187

[github-actions]

This issue is stale because it has been open 90 days with no activity. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled

[github-actions]

This issue was closed because it has been marked as stale for 30 days with no activity.