Gérer les erreurs du SDK Python sans dupliquer les résolutions

La méthode solve du SDK Python synchrone crée une tâche une seule fois et l’interroge jusqu’à ce qu’elle soit prête ou qu’une erreur soit levée. Interceptez les exceptions spécifiques avant SolvethreeError pour pouvoir distinguer une résolution échouée d’une requête HTTP interrompue.

Définissez SOLVETHREE_API_KEY et SOLVETHREE_PROXY, puis remplacez le nom d’hôte et l’action de l’exemple par les valeurs de votre cible. Le site doit disposer d’un profil actif dans l’espace de travail avant de pouvoir faire l’objet d’une résolution.

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 tâche a atteint le statut définitif failed. Examinez error.task_id et error.error_code ; ne continuez pas à interroger cette tâche.
• ApiError : une requête HTTP a échoué. Examinez error.status et error.retry_after, exprimé en secondes. Il ne s’agit pas d’un échec définitif de la tâche.
• SolvethreeError : conservez error.request_id et error.task_id pour une reprise explicite. Utilisez les identifiants disponibles au lieu de supposer que la création n’a jamais eu lieu.

L’exemple affiche les informations de reprise, mais ne les conserve pas durablement et n’effectue pas de reprise. Dans une intégration qui doit résister à un redémarrage du processus, enregistrez les données d’entrée d’origine de la tâche et l’identifiant de requête avant d’appeler solve, puis conservez tout identifiant de tâche renvoyé. Protégez les données d’entrée stockées qui contiennent des identifiants de connexion au proxy.

1. 1.

   Si vous disposez d’un task_id, reprenez avec get_task

   Récupérez cette tâche au lieu de rappeler solve. get_task accepte l’identifiant de tâche et un argument wait_ms ; son attente par défaut est de 15000 millisecondes. Continuez tant que le statut est pending ou solving. N’utilisez la solution que lorsque le statut est ready, et arrêtez-vous sur failed.

2. 2.

   Si la création a été interrompue avant la réception d’un identifiant de tâche, relancez create_task

   Envoyez les mêmes données d’entrée avec le même requestId, en utilisant le request_id récupéré si nécessaire. Réutiliser cet identifiant avec la même requête renvoie la tâche existante ; modifier les données d’entrée provoque un conflit. Une fois l’identifiant de tâche obtenu, continuez avec get_task.

3. 3.

   Ne générez pas d’autre identifiant pendant la reprise

   L’exemple génère son UUID avant d’appeler solve. Conservez cette valeur lors de la reprise ; ne reconstruisez pas la tâche au risque de la remplacer accidentellement. Un nouvel identifiant représente une requête distincte, pas une nouvelle tentative de la requête interrompue.

Le SDK génère un requestId si vous l’omettez, expose les identifiants de reprise dans les erreurs et ne réessaie jamais automatiquement la création d’une tâche. Pendant solve, il respecte Retry-After pour les échecs temporaires d’interrogation, dans la limite du délai de résolution. Si l’appel lève malgré tout une exception, utilisez les identifiants enregistrés pour reprendre au lieu de lancer une autre résolution.

Pour ApiError, examinez l’erreur HTTP avant de décider de renvoyer quoi que ce soit. Reprendre une création interrompue est approprié lorsque son résultat est incertain ; renvoyer aveuglément des données d’entrée invalides inchangées ne l’est pas.

Pour TaskFailedError, la tâche est terminée. Une tâche échouée récupérée contient errorCode et error ; l’exception Python expose le code via error.error_code. Utilisez ces informations pour déterminer ce qui doit changer. Par exemple, site-unreachable nécessite de vérifier l’accessibilité de la cible, et non de supposer que le compte manque de crédit. Les résolutions échouées sont remboursées.