feat(tracer): Add capability to continue traces comming from SQS triggers

[flochaz]

🚧 WIP 🚧 :

• Missing proper unit and e2e tests assertions
• Need to evaluate the API design :
  • is continueSQSRecordTrace and the way to invoke it good enough ?
  • Should we store toCloseSegments on our side and provide a function to close them ?
• can we really can't do better in term of implementation ???
  • might worth to contact a xray sdk node developer
  • check in deeper details what is done here https://github.com/Sam-Martin/aws-xray-lambda-segment-shim

Description of your changes

This PR is a first draft trying to give a solution to the Xray node sdk issue aws/aws-xray-sdk-node#208 where traces should be continued when lambdaare triggered from SQS: Producer -> SQS -> Consumer Lambda -> ... (Today it creates 2 traces: Producer -> SQS and Lambda -> ...).

Here are the findings while implementing this:

• aws-xray-sdk-node has a specific behavior for lambda based on process.env.LAMBDA_TASK_ROOT (https://github.com/aws/aws-xray-sdk-node/blob/master/packages/core/lib/aws-xray.js#L381)
• Even if active tracing is disabled on the consumer lambda a trace is created for the Consumer Lambda
• If XRay permission is not granted to consumer then no traces are created.
• We can force env var _X_AMZN_TRACE_ID but
  • need to be set before import of the xray-sdk-core
  • it does not prevent the extra trace to be created with a different traceID
  • It does not help with the multi message use case

How to verify this change

cd packages/tracing
export DISABLE_TEARDOWN=true
npx jest --group=e2e/tracer/sqs

Check Xray for traces

Or Cloudwatch Service Map

Related issues, RFCs

#286

PR status

Is this ready for review?: NO
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published in downstream module
• The PR title follows the conventional commit semantics

Breaking change checklist

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

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

[simonireilly]

ref

[flochaz]

Waiting for X-Ray Service team strategy. Closing for now ...