-
-
Notifications
You must be signed in to change notification settings - Fork 358
Open
Labels
Description
Describe the bug
I want requests to retry for connection errors, but responses seems to override the adapter send function and doesn't retry in that case. Is there an easy way to test only for exception cases?
Additional context
No response
Version of responses
0.25.7
Steps to Reproduce
import responses
from requests import Session
from requests.adapters import HTTPAdapter
from requests.exceptions import ConnectTimeout
from responses.registries import OrderedRegistry
from urllib3.util import Retry
@responses.activate(registry=OrderedRegistry)
def test_example():
session = Session()
# Note, no status_forcelist set
retry = Retry(total=3, allowed_methods={"POST"})
session.mount("http://", HTTPAdapter(max_retries=retry))
url = "http://example.com/api"
# This won't retry, doesn't honor Retry-After
responses.post(url, body="Error", status=503, headers={"Retry-After": "1"})
# This won't retry, it raises the exception though
responses.post(url, body=ConnectTimeout())
# This is never matched
responses.post(url, body='{"message": "It worked."}', status=200)
response = session.post(url, data={"key": "value"})
# This assertion fails, status_code is 503
assert response.status_code == 200
Expected Result
I expected responses to have a way to test retries from exceptions since it has the nice retry testing feature, but I didn't expect that status_forcelist was required. I actually consider this a feature expansion, but I was asked to open it as a bug.
Actual Result
For exceptions, responses doesn't retry. For statuses, it looks like it doesn't check for Retry-After header, only status_forcelist due to how urllib3 works. Personally, I'm interested in the exception case, and didn't look much at the Retry-After case.
JPDSousa and sshishov
Metadata
Metadata
Assignees
Labels
Projects
Status
Waiting for: Product Owner