Inconsistent number validation

[mbellqq]

Describe the bug

Numeric parameters to methods can have upper and lower bounds set. However the validation step does not validate that a parameter is less than a given upper bound (only that it is greater than a given lower bound). This results in invalid values being sent to AWS and so calls fail with a botocore.exceptions.ClientError exception instead of a botocore.exceptions.ParamValidationError exception (like they do when a lower bound is violated).

Regression Issue

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

Expected Behavior

The example below should raise a ParamValidationError exception (similar to when MaxSessionDuration=1) e.g.

botocore.exceptions.ParamValidationError: Parameter validation failed:
Invalid value for parameter MaxSessionDuration, value: 1000000, valid min value: 3600, max value 43200

Current Behavior

The below example fails with a ClientError:

botocore.exceptions.ClientError: An error occurred (ValidationError) when calling the CreateRole operation: 1 validation error detected: Value at 'maxSessionDuration' failed to satisfy constraint: Member must have value less than or equal to 43200

Reproduction Steps

import json
import boto3

iam = boto3.client("iam")

trust = json.dumps(
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Service": "lambda.amazonaws.com"
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }
)

iam.create_role(AssumeRolePolicyDocument=trust, RoleName="duration-too-high", MaxSessionDuration=1_000_000)
# MaxSessionDuration should be between 3600 and 43200.

Possible Solution

Add additional validation to The range_check function so that if value > shape.metadata['max'] then the check is also set to failed.

Additional Information/Context

No response

SDK version used

1.35.99

Environment details (OS name and version, etc.)

MacOS

[RyanFitzSimmonsAK]

Hi @mbellqq, thanks for reaching out. This is a known issue, and we have an existing tracking issue for issues about the lack of upper bound client-side validation. I'm going to close this issue as a duplicate, and I encourage you to mention this behavior (not raising the correct error) in that issue. Thanks!