-
-
Notifications
You must be signed in to change notification settings - Fork 185
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
No retries for ServerTimeoutError #876
Comments
taking a look |
interesting, it will retry if you don't specify |
I'm going to refactor aiohttp to be behind httpsession.py like in botocore for more parallelism and to have the exception wrappers behave similarly |
Ooh, interesting. Thanks for taking a look! Sounds like a workaround for now would be to not specify Thanks again, will look forward to the fix. |
@mariaines if you wouldn't mind testing the fix that would be great, thanks! I added a integration test so it won't happen again |
Sure, happy to, but will need to figure out how to install from github via aws sam... investigating Edit: can install from git in requirements.txt :), deploying... |
to all those following this, you now have to set the |
Describe the bug
Hi, we seem to be experiencing no retries for ServerTimeoutErrors, despite passing in a config with standard retry mode and total_max_attempts=5. We see occasional ServerTimeoutErrors across various clients (dynamodb, sqs, apigateway). We have a separate production app that uses just boto3 and it never sees these ServerTimeoutErrors (using the default botocore config which I understand has standard retry mode and total_max_attempts=3).
Including a screenshot of a Sentry error that shows attempts = 1 by the time we raise the exception, indicating it was not retried. We also have timing logs that show the dynamo call fails after 10s, which is our configured connect_timeout.
sample code:
Checklist
pip check
passes without errorspip freeze
resultspip freeze results
Environment:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: