-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Misalignment between custom botocore.config retry parameters and the time it takes to raise ConnectTimeoutError #3298
Comments
Hi @mgilar, thank you for reaching out. I was able to get the same error ConnectTimeoutError using your sample code and set up (CloudWatch and SageMaker) but in order to get the error I had to set my "connect_timeout" and "read_timeout" very low as possible (for example 0.000001). When it is at 1, it works fine. For a further look, could you please provide your used case for the test and also to provide the full debug logs by adding the line: boto3.set_stream_logger('') and redacting any sensitive information. And also if possible, to provide the full code that you may have and any further related logs. Thank you. |
Hi @adev-code, let me provide further details on the above mentioned issue:
The obtained logs are:
Let me know if I can provide further information |
Describe the bug
When connection cannot be stablished using a CloudWatch boto3 client, the time it takes to raise the ConnectTimeoutError does not match the time it should take given the custom parameters defined using the botocore.config Config class.
The time to raise the connection error consistently takes three times the max. number of retrials or max timeout time.
Regression Issue
Expected Behavior
Given the following custom configuration to be applied in a CloudWatch boto3 client:
After testing the retrials behaviour when the connection cannot be stablished, with different parameter configurations I obtain the following execution times (time difference between cloudwatch.PutMetricData is logged and the ConnectTimeoutError is raised):
Current Behavior
After testing the retrials behaviour when the connection cannot be stablished, with different parameter configurations I obtain the following execution times (time difference between cloudwatch.PutMetricData is logged and the ConnectTimeoutError is raised):
Reproduction Steps
Create the following custom configuration to be applied in a CloudWatch boto3 client:
Execute the code from an AWS Service that does not have permissions to access/write Cloudwatch metrics (in my case it was a Sagemaker endpoint).
Package versions
botocore = 1.35.58
boto3 = 1.35.58
urllib3 = 2.2.3
Possible Solution
It looks like the source of the problem (see additional info/context to check full error logs) is related to urllib connection session parameters not being overwritten by custom retry parameters. Therefore urllib connection is executed as many times as its default parameter: 3.
Additional Information/Context
The full error obtained when connection cannot be established is:
SDK version used
1.35.58
Environment details (OS name and version, etc.)
Linux
The text was updated successfully, but these errors were encountered: