The areas I was thinking of are:

• Dumping raw responses from the AWS SDK
• Turning on the ConsoleSpanExporter (it's commented out right now)
• Turning on the OTEL SDK's internal diagnostic logging

I'm mostly unsure as to the best CLI flag/parameter to use for this (should this be consistent with the aws cli? Or the other cfn binary tools? Or have a separate loglevel input? Or a verbosity flag? What happens if it doesn't only use logs at some point? And so on and so forth...)

Haven't reproduced this yet, but I realized that the for every stack that's encountered in the set of nested stacks, the tool currently tries to work with events from the latest deploy from each of them.

However those aren't necessarily from the latest deploy of the root stack. Like if you had a substack that was created once and never touched again, the code as-is would try to pull in its events even when trying to analyze the latest deploy of the root stack.

The code should instead ignore any events from any stack that precede the event that marks the start of the most recent deploy of the root stack.

The screenshot from the READme illustrates this pretty well.

This doc from otel-js seems to confirm that the "service.name" standard attribute from the opentelemetry spec needs to be set on the spans for this.

Maybe "Cloudformation" is a good default name to hard-code to start with?

I kind of want to avoid letting the binary read from users' ~/.aws/ directory automatically, so the other option that came to mind was passing things like the access key, secret, and region as CLI parameters.

I'm not sure how much this would improve ergonomics of using the binary (maybe simplifies certain CI usage?) but wanted to at least capture the idea here.

Right now deno fmt is being run in CI mostly to check for anything brazenly wrong with the files.

Instead of having folks have to remember to run make format before publishing a PR, it seems like it'd be nice to just automatically do that for them in CI (or a pre-commit-hook if there's a simple, non-obtrusive option for that)

I didn't see any ready made recipe for doing this with Deno (or an out-of-the-box solution) like I believe Prettier's ecosystem has, but I'm sure there's a pattern to follow somewhere that just needs to be found and tried out.

This is coming from the code not currently handling pagination of the AWS JS SDK calls at all (it's just making one call and calling that good).

This AWS doc about when pagination starts suggests its around when the response gets to 1 MB. When I measured the hollow-nesting-only (root) stack it came out to about 4000 bytes per deploy, which implies that it's roughly when a stack is 250 times as big (so like 250 resources) when problems would start to appear

Right now the binary only works on (root) stack updates, because mvp and whatnot.

It should also work on stacks that were just created as well.

Cloudformation stacks can output values (link to AWS doc on outputs) that can be used in other stacks, but this info isn't visible in the converted span data anywhere right now.

It might be cool to add this info somewhere on the span corresponding to each stack (and make it more easily searchable probably too).

Right now the help documentation for the CLI is present in the READme, but that's kind of not where anyone would probably anticipate it being when trying to use this tool if I had to guess.

Instead, it would be nice to be consistent with other CLI tools and offer a --help or similar option that lists out what is possible to do with the CLI and other helpful pointers

I thought release-it was supposed to include all commits since the previous tagged release, but maybe I misunderstood (or the defaults)

I haven't looked into this yet, but I suppose a workaround is to manually edit the release notes afterwards to give more info on what's changed.

Right now just to get an end-to-end flow working with the binary, you also have to get an OpenTelemtery Collector setup and working, which is at a minimum annoying.

It might simplify setup to create something that bundles both the binary and the OpenTelemetry Collector together (e.g. like a docker image) that you can just download and immediately run and get results.

Cloudformation stacks can take in parameters, but this info isn't visible in the converted span data anywhere right now.

It might be cool to add this info somewhere on the span corresponding to each stack (and make it more easily searchable probably too).

Right now the tool assumes a happy path of a stack update working without issue.

However in reality a stack might fail to create or update for some reason (and usually rollback).

It would be cool to handle those scenarios, maybe marking relevant spans as error spans and adding attributes for the brief text blurbs Cloudformation gives on its error events.

Right now it's hard-coded to point to http://localhost:4318/v1/traces since that's where it expects a local OpenTelemetry collector to be listening.

However I'm assuming folks might want to point the binary to export to deployed collectors not on their machine.