I put together a POC for local AWS Xray support when running

npx sst start

. Would this be of any use for closing serverless-stack#123?

Interesting! In #123, I was thinking to disable x-ray as it would give an error b/c the x-ray daemon isn’t available locally.

That's a great question 👍 Certainly I don't think using x-ray as a debugging tool for local development would be effective. The traces are useful for more complex tasks e.g if attempting to convert a lambda with multiple DynamoDB gets and puts, into one that is idempotent, through a single DynamoDB transaction. X-ray is a good tool here as you can check that you aren't making other calls or side-effects, particularly in larger code bases with multiple maintainers. e.g ensure we mutate the database then send the sqs message. These are activities typically covered in integration or component testing that x-ray can be used to visualise and debug. X-ray is also useful if you are doing more orchestration type tasks e.g. checking FIFO queue ordering to dead letter behaviour etc. You should be able to see three retries and then dlq for example. Which is not something typically tested in an integration or smoke test. In that sense, it lends itself to more of an integration and performance focussed debugging session. So the final thing really is in regard to testing x-ray itself. • Have you configured sampling rules? • Is there additional metadata or annotations being added that need debugging as they look wrong? • Have your custom subsegments instrumented correctly? • Is there personal identifiable information appearing in your annotations and you need to tests and debug you parameter whitelist? I think for these cases having a fast iteration cycle like

npx sst start

is useful, but these tasks are not impossible without it.

Right, that makes a lot of sense. Do you want to open a PR with what you have?

I will take a look at encapsulation and error handling, but I can open a PR into the main repo for visibility and tracking 👍

Awesome! Thanks @Simon Reilly