question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

urllib3 Retry and Response Hooks (Duplicates #4514)

See original GitHub issue

Given you have a session, and have successfully attached the auth class and the response hooks accordingly; although you’d like to add the Retry class into the picture from urllib3.

Expected Result

I’d expect the response hooks to be honoured - at the very least on the first response (not retry).

Actual Result

The response hooks are ignored completely.

Reproduction Steps

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry

retry = Retry(total=1, read=1, connect=1, backoff_factor=0.5,
                      status_forcelist=(401, 500))

adapter = HTTPAdapter(max_retries=retry)

session = requests.Session()
session.hooks = {'response': response_hook}

session.mount('http://', adapter)
session.mount('https://', adapter)

def response_hook(response, *args, **kwargs):
    """
    Response hook

    :param response:
    :return:
    """
    if response.status_code == requests.codes.unauthorized:
       print('Your logic here')

System Information

Python version: 3.5
Requests version: 2.11.0
OS: Ubuntu 16.04

Issue Analytics

  • State:open
  • Created 5 years ago
  • Reactions:2
  • Comments:5 (1 by maintainers)

github_iconTop GitHub Comments

1reaction
zupocommented, Feb 2, 2021

Just got bitten by the same thing myself too. I was assuming hooks would work, until I dug deeper.

1reaction
sigmavirus24commented, Jul 25, 2018

@belthaZornv can you share what part of our documentation misled you here?

Retry logic from urllib3 operates at a much lower level than the response hook(s). You have specified 401 as a status code to retry which means that Requests will never see it. It will be retried by urllib3 before we can execute the hook. I thought our documentation was clear that the Retry logic operated at a very low level and caused other parts of Requests to behave differently. If I’m mistaken, please point out where you saw differently.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Scrapy Documentation - Read the Docs
By default, Scrapy filters out duplicated requests to ... hooks to Python's re module. ... urllib.parse.urljoin(response.url, url).
Read more >
T185561 weblinkchecker.py slows down (itself, OS) to freeze ...
RemoteDisconnected: Remote end closed connection without response During handling of the above exception, another exception occurred: Traceback (most recent ...
Read more >
IBM/watson-assistant-workbench - Travis CI
2247 Pass ``None`` to retry until you receive a response. Pass a. 2248 :class:`~urllib3.util.retry. ... 11242 hooks=hooks,.
Read more >
Read the Docs Documentation
smooth as possible, like installing webhooks. ... response times are unaffected as the delivery of resources ... urllib3==1.26.9.
Read more >
Salt Documentation - manpages.ubuntu!
Test that your minion is responding On the salt-master run: sudo salt ... TCP. tcp_master_pull_port: 4513 tcp_master_publish_pull Default: 4514 The TCP port ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found