Gestiona los errores del SDK de Python sin duplicar las resoluciones

El método solve del SDK síncrono de Python crea una tarea una sola vez y la sondea hasta que está lista o lanza un error. Captura las excepciones específicas antes de SolvethreeError para poder distinguir una resolución fallida de una solicitud HTTP interrumpida.

Configura SOLVETHREE_API_KEY y SOLVETHREE_PROXY y sustituye el nombre de host y la acción del ejemplo por los valores de tu destino. El sitio necesita un perfil activo en el espacio de trabajo antes de poder resolverlo.

import os
import uuid
from solvethree import Solvethree, ApiError, TaskFailedError, SolvethreeError

client = Solvethree(os.environ["SOLVETHREE_API_KEY"])
task = {"site": "accounts.example.com", "action": "login", "proxy": os.environ["SOLVETHREE_PROXY"], "requestId": str(uuid.uuid4())}
try:
    result = client.solve(task, timeout=180)
    print("Ready task:", result["id"])
    # Submit result["solution"] privately through the target application.
except TaskFailedError as error:
    print("Failed task:", error.task_id, "code:", error.error_code)
    # This task is terminal. Inspect it before starting different work.
except ApiError as error:
    print("HTTP status:", error.status, "retry delay:", error.retry_after)
    print("Recovery IDs:", error.request_id, error.task_id)
    # A known task_id means resume get_task; otherwise replay the exact task
    # with error.request_id. Do not generate a new logical request to recover it.
except SolvethreeError as error:
    print("Recovery IDs:", error.request_id, error.task_id)
    # Save these IDs and the original task inputs for explicit recovery.

• TaskFailedError: la tarea alcanzó el estado terminal failed. Inspecciona error.task_id y error.error_code; no sigas sondeando esa tarea.
• ApiError: una solicitud HTTP falló. Inspecciona error.status y error.retry_after, que se mide en segundos. Esto no equivale a un fallo terminal de la tarea.
• SolvethreeError: conserva error.request_id y error.task_id para una recuperación explícita. Usa los ID que estén disponibles en lugar de asumir que la creación nunca se produjo.

El ejemplo imprime la información de recuperación, pero no la guarda de forma persistente ni realiza la recuperación. En una integración que deba resistir un reinicio del proceso, guarda los datos originales de la tarea y el ID de solicitud antes de llamar a solve y conserva después cualquier ID de tarea devuelto. Protege los datos almacenados que contengan credenciales del proxy.

1. 1.

   Si tienes un task_id, reanuda get_task

   Recupera esa tarea en lugar de volver a llamar a solve. get_task acepta el ID de tarea y un argumento wait_ms; su espera predeterminada es de 15000 milisegundos. Continúa mientras el estado sea pending o solving. Usa la solución solo cuando el estado sea ready y detente si es failed.

2. 2.

   Si la creación se interrumpió antes de que recibieras un ID de tarea, vuelve a ejecutar create_task

   Envía exactamente los mismos datos de la tarea con el mismo requestId, usando el request_id recuperado cuando sea necesario. Reutilizar ese ID con la misma solicitud devuelve la tarea existente; cambiar los datos provoca un conflicto. Una vez que tengas su ID de tarea, continúa con get_task.

3. 3.

   No generar otro ID durante la recuperación

   El ejemplo genera su UUID antes de llamar a solve. Conserva ese valor durante la recuperación; no vuelvas a ejecutar la construcción de la tarea y lo sustituyas por accidente. Un ID nuevo representa una solicitud distinta, no un reintento de la que se interrumpió.

El SDK genera un requestId si lo omites, expone los ID de recuperación en los errores y nunca reintenta automáticamente la creación de tareas. Durante solve, respeta Retry-After para los fallos temporales de sondeo dentro del plazo de resolución. Si la llamada sigue lanzando una excepción, usa los ID guardados para reanudarla en lugar de iniciar otra resolución.

En el caso de ApiError, inspecciona el error HTTP antes de decidir si vuelves a enviar algo. Recuperar una creación interrumpida es adecuado cuando el resultado es incierto; reenviar a ciegas los mismos datos no válidos no lo es.

En el caso de TaskFailedError, la tarea ha terminado. Una tarea fallida recuperada contiene errorCode y error; la excepción de Python expone el código como error.error_code. Usa esa información para decidir qué debes cambiar. Por ejemplo, site-unreachable requiere investigar la accesibilidad del destino, no asumir que la cuenta carece de crédito. Las resoluciones fallidas se reembolsan.