Excessive service module version churn

[ewbankkit]

Acknowledgements

• I have searched (https://github.com/aws/aws-sdk/issues?q=is%3Aissue) for past instances of this issue
• I have verified all of my SDK modules are up-to-date (you can perform a bulk update with go get -u github.com/aws/aws-sdk-go-v2/...)

Describe the bug

Over recent weeks there have been a number of releases where every service module's version has increased and the only change for those services without API model changes has been a re-ordering of calls inside the service's New function.
For example with yesterday's 2024-10-03 release for the accessanalyzer service, calls to resolveTracerProvider and resolveMeterProvider were swapped. This module had no functionality changes but a new version of the module was published.

This module version churn causes projects that use many service modules (e.g. terraform-provider-aws) to update a large number of dependencies and can cause a problem with dependabot timeouts.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Service module only publish new versions when there is new functionality (or their own dependencies change).

Current Behavior

Excessive module version churn.

Reproduction Steps

n/a

Possible Solution

No response

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

n/a

Compiler and Version used

go 1.23.1

Operating System and version

linux

[lucix-aws]

Do you have any examples of this happening for something other than resolveTracerProvider and resolveMeterProvider?

The order of codegen for these two is evidently unstable - just checked on my own system, and I can re-generate multiple times and get either result. The abstraction through which they're inserted uses a HashMap, which is very much not guaranteed to retain order. The outer "plugin" abstraction is ordered, but in this case, observability was implemented as one plugin with two hashset insertions for each resolver. How we have only run into this now, I have no idea. 🤦

Unfortunately the release is about to happen again and so there's a 50/50 chance it'll swap today. We'll stabilize the order to prevent it in the future, at least.

[lucix-aws]

I have a patch ready. Waiting to see what the order is in today's release so I can match that (which would prevent an extra chrun on monday's release).

[ewbankkit]

@lucix-aws In my (relatively rather superficial) investigations I've only seen resolveTracerProvider and resolveTracerMeter swap.

[lucix-aws]

We've structured things to be ordered in codegen by design (e.g. struct members are sorted, generated serde is sorted) to avoid exactly this kind of churn-- so this should be an exception rather than the rule.

[lucix-aws]

aws/smithy-go#545

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.