-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Excessive service module version churn #2819
Comments
Do you have any examples of this happening for something other than 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. |
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). |
@lucix-aws In my (relatively rather superficial) investigations I've only seen |
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. |
This issue is now closed. Comments on closed issues are hard for our team to see. |
Acknowledgements
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 theaccessanalyzer
service, calls toresolveTracerProvider
andresolveMeterProvider
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 withdependabot
timeouts.Regression Issue
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
The text was updated successfully, but these errors were encountered: