Celery es un potente framework que soporta el procesamiento de tareas asíncronas. El decorador @shared_task se utiliza para definir tareas, y al emplear las opciones bind, autoretry_for, retry_backoff, max_retries, se puede mejorar significativamente la estabilidad de las tareas y la gestión automática de errores.

En este artículo, exploraremos cómo funcionan estas opciones y cómo utilizarlas, además de presentar las mejores formas de resolver la confusión que a menudo surge.

1. bind=True

Definición

bind=True permite pasar la tarea actual como el primer parámetro, lo que permite utilizar self dentro de la tarea. Esto proporciona acceso al estado de la tarea, métodos, propiedades, etc.

Funciones clave

• Acceso al estado de la tarea: Se puede acceder al ID de la tarea, información de solicitud, etc., para verificar el estado o registrarlo.
• Logica de reintento explícita: Se puede implementar manualmente la lógica de reintentos a través del método self.retry().

Ejemplo

@shared_task(bind=True)
def my_task(self, some_arg):
    print(f"ID de tarea: {self.request.id}")  # Imprimir el ID de la tarea
    self.retry()  # Reintentar la tarea

2. autoretry_for=(ExceptionType,...)

Definición

Configura a Celery para que reintente automáticamente la tarea cuando se produzca una excepción especificada. No es necesario que el desarrollador llame explícitamente a self.retry() para gestionar las excepciones y automatizar los reintentos.

Puntos a considerar

• Uso de autoretry_for: Dado que los reintentos se realizan automáticamente, debe asegurarse de que self.retry() no se use de forma redundante.
• Problemas al combinar: Utilizar autoretry_for y self.retry() simultáneamente puede provocar reintentos duplicados para la misma excepción.

Ejemplo

Forma recomendada: usar solo autoretry_for

import requests

@shared_task(bind=True, autoretry_for=(requests.RequestException,), retry_backoff=True)
def my_task(self, url):
    response = requests.get(url)
    response.raise_for_status()  # Lanza excepción si el código de estado no es 200

Uso de reintento explícito solo en condiciones específicas (self.retry())

import requests

@shared_task(bind=True, retry_backoff=True, max_retries=5)
def my_task(self, url):
    try:
        response = requests.get(url)
        response.raise_for_status()
    except requests.RequestException as e:
        print(f"Reintentando debido al error: {e}")
        self.retry(exc=e)  # Reintento explícito

3. retry_backoff=True

Definición

Activa el retroceso exponencial (Exponential Backoff), que incrementa el intervalo entre reintentos. El primer reintento se realiza de inmediato, y los siguientes aumentan a intervalos de 1 segundo, 2 segundos, 4 segundos, etc.

Funciones clave

• Reduce la carga del servidor y gestiona eficazmente las interrupciones de red.
• Los tiempos de retroceso se pueden personalizar a través de la configuración predeterminada de Celery.

Ejemplo

@shared_task(bind=True, autoretry_for=(requests.RequestException,), retry_backoff=True)
def my_task(self):
    # El primer reintento es después de 1 segundo, el segundo después de 2 segundos...
    raise requests.RequestException("Fallo simulado")

4. max_retries

Definición

Limita el número máximo de reintentos de una tarea. Si la tarea no tiene éxito después de los intentos especificados, se registra como fallida.

Funciones clave

• Previene reintentos infinitos, limitando el consumo de recursos del servidor.
• Permite registrar la tarea o ejecutar otra lógica según las condiciones de falla.

Ejemplo

@shared_task(bind=True, autoretry_for=(requests.RequestException,), retry_backoff=True, max_retries=5)
def my_task(self):
    raise requests.RequestException("Fallo simulado")

5. Precauciones al combinar: autoretry_for vs self.retry()

Guía de uso correcta

1. Cuando se usa autoretry_for: Dado que se establece la reintento automático, no es necesario llamar explícitamente a self.retry(). Puede escribir código más conciso simplemente reintentando la tarea para excepciones específicas.
2. Al usar self.retry(): Úselo cuando sea necesario realizar acciones adicionales antes del reintento (por ejemplo, escribir logs, verificación de condiciones específicas). Asegúrese de que autoretry_for no se use de forma redundante.

6. Resumen de opciones

7. Conclusión

Las opciones de @shared_task de Celery son útiles para gestionar fallos de tareas de manera efectiva y aumentar la estabilidad.

• Cuando se usa autoretry_for: Es automático, por lo que se debe tener cuidado de no duplicarse con self.retry().
• Si necesita lógica condicional o acciones adicionales, puede utilizar self.retry().

¡Optimice su código combinando estas opciones para implementar tareas de manera confiable utilizando Celery! 😊