Limiting the number of retries is a way of increasing your applications performance. This lesson shows you how to do that by implementing a custom HTTP adapter. If you don’t know about adapters: don’t worry! You’ll learn about them in this lesson, too.
Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Hint: You can adjust the default video playback speed in your account settings.
Hint: You can set your subtitle preferences in your account settings.
Sorry! Looks like there’s an issue with video playback 🙁 This might be due to a temporary outage or because of a configuration issue with your browser. Please refer to our video player troubleshooting guide for assistance.
Limiting Retries
00:00
By default, requests will not retry after a failed request, but what we can do is we can set up a custom Transport Adapter that can be mounted to a Session.
00:09
This allows a set of custom configurations per service, and we can set up a parameter for a maximum number of retries. As long as we’re in that Session and that transport adapter is mounted, it will use those parameters and in this case, do the multiple retries.
00:25
Let’s check it out. Okay. Let’s create a new file. We’ll call it max_retries.py. For it, we’ll import requests, and then from requests.adapters we’ll import the HTTPAdapter, and then we’ll import an exception that would check for a ConnectionError.
00:56
So, let’s create our specific adapter for GitHub. We’ll call it github_adapter, and we’ll set a parameter inside of it with the max_retries.
01:07
We’ll set it to 3. We’ll create a session.
01:14
We’re going to use the github_adapter for all requests to endpoints that start with this URL. So do that, we’ll do session, and then we need to mount that adapter for this URL. A try and except here.
01:40
It will except as a ConnectionError. We’ll save that as ce, and if we get that exception, we’ll print it. All right, let’s save.
01:51
We can run this here, and we got… ope. Let me change that a little bit. So, we’re going to except ConnectionError as ce:—and our colon is here—and print().
02:09
We resave and retry, and it looks like we had no issues. The main purpose of showing this is to show how a Transport Adapter works and how it applies to a specific URL and how to mount it to a Session.
techsukenik on Sept. 16, 2021
@Mahidhar Nyayapati the retries are at the adapter level not the session level. When the session.get is issued, the adapter will try 3 times to try to get a return. A Use Case is sometimes the connection will fail to connect and we would like the adapter try to connect again.
Both of the Use Cases you presented are not relevant to the adapter retries.
Case 1: You should disable the button so the user cannot submit the form multiple times.
Become a Member to join the conversation.
Mahidhar Nyayapati on Oct. 22, 2019
Did not understand the significance of sessions object and retries.
Could you please explain where can sessions object be used. I mean applications.
Why does it mean when you say “requests will not try after a failed request”. How does it work in other applications.
Case1: Payment gateway: If suppose a user clicked the “Pay” button and we set the max_retries > 2. If he does not get a quick feedback, he will surely press the button again and again. In that case he will be paying the same amount multiple times though he requested only once.
Case2: A user forgot his pasowrd and he is trying different combination of passwords, lets say after 10 the website blocks him(Banking sites usually stop at 3). Some websites say “limit exceeded. Try again later.” How do they implement the max_retries in this case.