¿Puedo configurar max_retries para request.request?

El módulo de solicitudes de Python es simple y elegante, pero una cosa me molesta. Es posible obtener un request.exception.ConnectionError con un mensaje como:

Max retries exceeded with url: ...

Esto implica que las solicitudes pueden intentar acceder a los datos varias veces. Pero no hay una sola mención de esta posibilidad en ninguna parte de los documentos. Mirando el código fuente, no encontré ningún lugar donde pudiera alterar el valor predeterminado (presumiblemente 0).

Entonces, ¿es posible establecer de alguna manera el número máximo de reintentos para las solicitudes?

Es la urllib3biblioteca subyacente la que vuelve a intentarlo. Para establecer un recuento máximo de reintentos diferente, use adaptadores de transporte alternativos :

from requests.adapters import HTTPAdapter

s = requests.Session()
s.mount('http://stackoverflow.com', HTTPAdapter(max_retries=5))

El max_retriesargumento toma un entero o un Retry()objeto ; este último le brinda un control detallado sobre qué tipos de fallas se reintentan (un valor entero se convierte en una Retry()instancia que solo maneja fallas de conexión; los errores después de que se realiza una conexión no se manejan de manera predeterminada, ya que podrían provocar efectos secundarios) .

Respuesta anterior, anterior a la publicación de solicitudes 1.2.1 :

La requestsbiblioteca realmente no hace que esto sea configurable, ni tiene la intención de hacerlo (consulte esta solicitud de extracción ). Actualmente (solicitudes 1.1), el recuento de reintentos está establecido en 0. Si realmente desea establecerlo en un valor más alto, deberá configurarlo globalmente:

import requests

requests.adapters.DEFAULT_RETRIES = 5

Esta constante no está documentada; úselo bajo su propio riesgo ya que las futuras versiones podrían cambiar la forma en que se maneja esto.

Actualización : y esto hizo el cambio; en la versión 1.2.1 se agregó la opción para establecer el max_retriesparámetro en la HTTPAdapter()clase , de modo que ahora tiene que usar adaptadores de transporte alternativos, consulte más arriba. El enfoque de parche de mono ya no funciona, a menos que también parchee los HTTPAdapter.__init__()valores predeterminados (no se recomienda mucho).

Esto no solo cambiará max_retries sino que también habilitará una estrategia de retroceso que hace que las solicitudes a todas las direcciones http: // se suspendan durante un período de tiempo antes de volver a intentarlo (hasta un total de 5 veces):

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

s = requests.Session()

retries = Retry(total=5,
                backoff_factor=0.1,
                status_forcelist=[ 500, 502, 503, 504 ])

s.mount('http://', HTTPAdapter(max_retries=retries))

s.get('http://httpstat.us/500')

De acuerdo con la documentación paraRetry : si el backoff_factor es 0.1 , sleep () dormirá durante [0.1s, 0.2s, 0.4s, ...] entre reintentos. También forzará un nuevo intento si el código de estado devuelto es 500 , 502 , 503 o 504 .

Varias otras opciones para Retrypermitir un control más granular:

• total : número total de reintentos para permitir.
• connect : cuántos errores relacionados con la conexión hay que volver a intentar.
• leer : cuántas veces volver a intentar errores de lectura.
• redirigir : cuántos redireccionamientos realizar.
• method_whitelist - Conjunto de verbos de métodos HTTP en mayúsculas en los que deberíamos volver a intentar.
• status_forcelist : un conjunto de códigos de estado HTTP en los que deberíamos forzar un reintento.
• backoff_factor : un factor de retroceso para aplicar entre intentos.
• raise_on_redirect : si, si se agota el número de redireccionamientos, para elevar MaxRetryErroro devolver una respuesta con un código de respuesta en el rango 3xx .
• raise_on_status: significado similar a raise_on_redirect : si debemos generar una excepción o devolver una respuesta, si el estado cae en el rango status_forcelist y los intentos se han agotado.

NB : raise_on_status es relativamente nuevo y aún no se ha convertido en una versión de urllib3 o solicitudes. Elargumento de la palabra clave raise_on_status parece haber llegado a la biblioteca estándar como máximo en python versión 3.6.

Para realizar solicitudes, vuelva a intentarlo con códigos de estado HTTP específicos, use status_forcelist . Por ejemplo, status_forcelist = [503] volverá a intentar el código de estado 503 (servicio no disponible).

De forma predeterminada, el reintento solo se activa para estas condiciones:

• No se pudo obtener una conexión desde el grupo.
• TimeoutError
• HTTPExceptionelevado (desde http.client en Python 3 más httplib ). Esto parece ser excepciones HTTP de bajo nivel, como URL o protocolo no formados correctamente.
• SocketError
• ProtocolError

Tenga en cuenta que estas son todas las excepciones que impiden recibir una respuesta HTTP normal. Si cualquiera se genera la respuesta normal, sin reintento está hecho. Sin usar el status_forcelist , incluso una respuesta con el estado 500 no se volverá a intentar.

Para que se comporte de una manera más intuitiva para trabajar con una API remota o un servidor web, usaría el fragmento de código anterior, que obliga a los reintentos en los estados 500 , 502 , 503 y 504 , todos los cuales no son infrecuentes en el web y (posiblemente) recuperable dado un período de retroceso lo suficientemente grande.

EDITADO : Importar Retryclase directamente desde urllib3 .

Tenga cuidado, la respuesta de Martijn Pieters no es adecuada para la versión 1.2.1+. No puede configurarlo globalmente sin parchear la biblioteca.

Puedes hacer esto en su lugar:

import requests
from requests.adapters import HTTPAdapter

s = requests.Session()
s.mount('http://www.github.com', HTTPAdapter(max_retries=5))
s.mount('https://www.github.com', HTTPAdapter(max_retries=5))

Después de luchar un poco con algunas de las respuestas aquí, encontré una biblioteca llamada backoff que funcionaba mejor para mi situación. Un ejemplo básico:

import backoff

@backoff.on_exception(
    backoff.expo,
    requests.exceptions.RequestException,
    max_tries=5,
    giveup=lambda e: e.response is not None and e.response.status_code < 500
)
def publish(self, data):
    r = requests.post(url, timeout=10, json=data)
    r.raise_for_status()

Todavía recomiendo darle una oportunidad a la funcionalidad nativa de la biblioteca, pero si tiene algún problema o necesita un control más amplio, el retroceso es una opción.

Una forma más limpia de obtener un mayor control podría ser empaquetar los elementos de reintento en una función y hacer que esa función sea recuperable usando un decorador y poner en la lista blanca las excepciones.

He creado lo mismo aquí: http://www.praddy.in/retry-decorator-whitelisted-exceptions/

Reproduciendo el código en ese enlace:

def retry(exceptions, delay=0, times=2):
"""
A decorator for retrying a function call with a specified delay in case of a set of exceptions

Parameter List
-------------
:param exceptions:  A tuple of all exceptions that need to be caught for retry
                                    e.g. retry(exception_list = (Timeout, Readtimeout))
:param delay: Amount of delay (seconds) needed between successive retries.
:param times: no of times the function should be retried


"""
def outer_wrapper(function):
    @functools.wraps(function)
    def inner_wrapper(*args, **kwargs):
        final_excep = None  
        for counter in xrange(times):
            if counter > 0:
                time.sleep(delay)
            final_excep = None
            try:
                value = function(*args, **kwargs)
                return value
            except (exceptions) as e:
                final_excep = e
                pass #or log it

        if final_excep is not None:
            raise final_excep
    return inner_wrapper

return outer_wrapper

@retry(exceptions=(TimeoutError, ConnectTimeoutError), delay=0, times=3)
def call_api():