Trate erros do SDK de Python sem duplicar resoluções

O método solve do SDK síncrono de Python cria uma tarefa uma vez e faz polling até que ela esteja pronta ou lance um erro. Capture as exceções específicas antes de SolvethreeError para distinguir uma resolução que falhou de uma requisição HTTP interrompida.

Defina SOLVETHREE_API_KEY e SOLVETHREE_PROXY e substitua o hostname e a ação do exemplo pelos valores do seu destino. O site precisa de um perfil ativo no workspace antes que seus desafios possam ser resolvidos.

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: a tarefa atingiu o estado terminal failed. Inspecione error.task_id e error.error_code; não continue consultando essa tarefa.
• ApiError: uma requisição HTTP falhou. Inspecione error.status e error.retry_after, que é medido em segundos. Isso não é o mesmo que uma falha terminal da tarefa.
• SolvethreeError: guarde error.request_id e error.task_id para recuperação explícita. Use os IDs disponíveis em vez de presumir que a criação nunca ocorreu.

O exemplo imprime as informações de recuperação, mas não as persiste nem executa a recuperação. Em uma integração que precisa sobreviver à reinicialização do processo, salve os parâmetros originais da tarefa e o ID da requisição antes de chamar solve e guarde qualquer ID de tarefa retornado. Proteja os parâmetros armazenados que contêm credenciais de proxy.

1. 1.

   Se você tiver um task_id, retome get_task

   Consulte essa tarefa em vez de chamar solve novamente. get_task aceita o ID da tarefa e um argumento wait_ms; a espera padrão é de 15000 milissegundos. Continue enquanto o status for pending ou solving. Use a solução somente quando o status for ready e pare em failed.

2. 2.

   Se a criação foi interrompida antes de você receber um ID de tarefa, reenvie create_task

   Envie os mesmos parâmetros da tarefa com o mesmo requestId, usando o request_id recuperado quando necessário. Reutilizar esse ID com a mesma requisição retorna a tarefa existente; alterar os parâmetros gera um conflito. Quando tiver o ID da tarefa, continue com get_task.

3. 3.

   Não gere outro ID durante a recuperação

   O exemplo gera seu UUID antes de chamar solve. Mantenha esse valor durante a recuperação; não execute novamente a construção da tarefa e o substitua acidentalmente. Um novo ID representa uma requisição separada, não uma nova tentativa da requisição interrompida.

O SDK gera um requestId se você o omitir, expõe IDs de recuperação nos erros e nunca repete automaticamente a criação de tarefas. Durante solve, ele respeita Retry-After para falhas temporárias de polling dentro do prazo da resolução. Se a chamada ainda lançar uma exceção, use os IDs salvos para retomar, em vez de iniciar outra resolução.

Para ApiError, inspecione o erro HTTP antes de decidir reenviar qualquer coisa. Recuperar uma criação interrompida é apropriado quando o resultado é incerto; reenviar cegamente parâmetros inválidos sem alterá-los não é.

Para TaskFailedError, a tarefa está encerrada. Uma tarefa com falha consultada contém errorCode e error; a exceção de Python expõe o código como error.error_code. Use essas informações para decidir o que precisa mudar. Por exemplo, site-unreachable exige investigar a acessibilidade do destino, não presumir que a conta está sem créditos. Os créditos de resoluções que falham são reembolsados.