-
Notifications
You must be signed in to change notification settings - Fork 605
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
Regression to number types with respect to SDKv2 #5198
Comments
we're not likely to implement this, because SDKs have a directive against doing most client side validation and type coercions. please convert the value at the SDK operation call site to its intended type. |
Hi @rix0rrr In the past versions of the AWS SDKs there were many customizations that were introduced over the years. The SDK organization as a whole has moved away from implementing customizations as they are not maintainable and instead, the newer SDKs are code generated directly from the API models of each AWS service and rely on the model to dictate the desired behavior. Since CodeDeploy specifies
Unfortunately there is no plan to introduce similar behavior of this sort. Thanks, |
…cted, skips recursive types (#27112) AWS SDK v3 strictly validates numeric types, as opposed to v2, which allowed, for example, "123" to be passed where an integer was expected. This script adds all attributes of a numeric type ("byte", "short", "integer", "long", "bigInteger", "float", "double" and "bigDecimal") to a new type coercion map. It also compacts the map by trimming each part of the path to its unique prefix among all the paths in its operation. We also change the data structure from a list of paths (forming a tree) to a graph/state machine. This is necessary in order to support self-recursive types, which can loop arbitrarily and therefore cannot be represented in fixed length prefix lists. See aws/aws-sdk-js-v3#5198 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…cted, skips recursive types (#27112) AWS SDK v3 strictly validates numeric types, as opposed to v2, which allowed, for example, "123" to be passed where an integer was expected. This script adds all attributes of a numeric type ("byte", "short", "integer", "long", "bigInteger", "float", "double" and "bigDecimal") to a new type coercion map. It also compacts the map by trimming each part of the path to its unique prefix among all the paths in its operation. We also change the data structure from a list of paths (forming a tree) to a graph/state machine. This is necessary in order to support self-recursive types, which can loop arbitrarily and therefore cannot be represented in fixed length prefix lists. See aws/aws-sdk-js-v3#5198 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…cted, skips recursive types (#27112) AWS SDK v3 strictly validates numeric types, as opposed to v2, which allowed, for example, "123" to be passed where an integer was expected. This script adds all attributes of a numeric type ("byte", "short", "integer", "long", "bigInteger", "float", "double" and "bigDecimal") to a new type coercion map. It also compacts the map by trimming each part of the path to its unique prefix among all the paths in its operation. We also change the data structure from a list of paths (forming a tree) to a graph/state machine. This is necessary in order to support self-recursive types, which can loop arbitrarily and therefore cannot be represented in fixed length prefix lists. See aws/aws-sdk-js-v3#5198 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread. |
Describe the feature
This issue is very similar to #5181.
Apparently, the same problem applies to
number
types. In SDKv2,number
types that are accidentally passed asstrings
, the SDK converts them to the right type silently.SDKv3 will not do the conversion, allowing the server call to fail because of mismatched types.
Example:
SDKv2
SDKv3
The call fails with:
Use Case
Why does this matter to us?
Same reason as in #5181, we allow users to drive SDK calls using arbitrary, user-controlled parameters that cannot be type checked. We are transparently migrating all SDKv2 calls to SDKv3 calls, and calls that used to work no longer work after the upgrade.
Proposed Solution
Accept the same argument types as in SDKv2
Other Information
No response
Acknowledgements
SDK version used
3.409.0
Environment details (OS name and version, etc.)
The text was updated successfully, but these errors were encountered: