Gérer l’interrogation périodique des tâches CAPTCHA et les dépassements de délai

waitMs contrôle la durée pendant laquelle une requête API attend un résultat avant de répondre. Il s’agit d’un paramètre de requête URL, et non d’un champ du JSON de la tâche. Les valeurs par défaut à la création diffèrent selon le produit ; l’interrogation par GET a sa propre limite.

Accordez au client HTTP suffisamment de temps pour couvrir l’attente demandée côté serveur et la latence réseau supplémentaire. Un délai d’expiration côté client plus court que l’attente côté serveur peut interrompre la réponse avant que vous ne receviez l’état actuel de la tâche.

La méthode solve des SDK officiels crée une seule fois la tâche et interroge son état jusqu’à l’obtention d’un résultat prêt ou d’une erreur. Python expose timeout en secondes et poll_interval en secondes ; Node.js expose timeoutMs et pollIntervalMs en millisecondes. Les paramètres documentés utilisent une échéance de résolution de trois minutes et un intervalle d’interrogation d’une seconde.

Pour un contrôle direct, Python fournit create_task et get_task ; Node.js fournit createTask et getTask. Suivez cette séquence :

1. 1.

   Définissez une échéance et créez une seule tâche

   Choisissez une échéance globale avant la création. Conservez un requestId avec les données exactes de la tâche pour pouvoir récupérer une création interrompue. Pour éviter toute attente à la création, sélectionnez explicitement une attente nulle.

2. 2.

   Enregistrez l’identifiant de tâche renvoyé et inspectez son statut

   La création peut déjà renvoyer un résultat final. Renvoyez la solution si le statut est ready. Si le statut est failed, inspectez errorCode et error, puis arrêtez-vous ; les résolutions échouées sont remboursées. Seuls les statuts pending et solving nécessitent de poursuivre les interrogations.

3. 3.

   Récupérez la même tâche tant qu’il reste du temps

   Utilisez GET /v1/tasks/:id, éventuellement avec une attente en interrogation longue allant jusqu’à 15000 ms. Traitez les réponses HTTP autres qu’un succès avant de lire une charge utile de succès. Si la réponse indique toujours pending ou solving, répétez la requête avec le même identifiant, sans créer une autre tâche.

4. 4.

   Arrêtez-vous à l’échéance

   Limitez chaque requête au temps restant, en prévoyant la latence réseau supplémentaire. À l’échéance, arrêtez la boucle locale et conservez l’identifiant de tâche pour la récupération. Ne requalifiez pas la tâche comme ayant échoué simplement parce que votre client a cessé d’attendre.

Cette requête récupère une tâche existante, avec une attente de 15 secondes côté serveur et un délai d’expiration de 30 secondes côté client. Définissez TASK_ID sur l’identifiant enregistré et conservez SOLVETHREE_API_KEY sur le serveur. Aucun de ces délais ne constitue une échéance globale pour une boucle d’interrogations répétées.

curl --fail-with-body --max-time 30 \
  "https://api.solvethree.com/v1/tasks/$TASK_ID?waitMs=15000" \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY"

Une réponse HTTP de succès peut contenir une tâche qui nécessite encore des interrogations. pending et solving ne sont pas des états finaux ; seul ready contient une solution utilisable. failed est un état final et inclut errorCode et error.

{
  "nonterminal": [
    {
      "id": "example-task",
      "status": "pending"
    },
    {
      "id": "example-task",
      "status": "solving"
    }
  ],
  "ready": {
    "id": "example-task",
    "status": "ready",
    "solution": {
      "token": "EXAMPLE_TOKEN",
      "userAgent": "EXAMPLE_USER_AGENT",
      "secChUa": "EXAMPLE_CLIENT_HINTS"
    }
  },
  "failed": {
    "id": "example-task",
    "status": "failed",
    "errorCode": "site-unreachable",
    "error": "target page did not respond"
  }
}

La réponse prête présentée ici contient un jeton reCAPTCHA. Kasada renvoie des en-têtes et TMPT renvoie une valeur de cookie brute à la place. Un résultat prêt signifie qu’une solution a été générée, et non que la cible en aval l’a acceptée. Si un jeton reCAPTCHA prêt est rejeté, passez du diagnostic des interrogations à la vérification du jeton soumis.

L’expiration du délai de connexion indique que le client n’a pas reçu de réponse complète. Elle ne prouve pas que la création a échoué. Avant de payer pour une autre résolution, récupérez la tâche que vous avez peut-être déjà créée.

1. 1.

   Si vous avez un identifiant de tâche, reprenez les interrogations par GET

   Récupérez la tâche correspondant à cet identifiant avec une nouvelle échéance locale à durée limitée. L’expiration du délai d’un GET ne justifie pas l’envoi d’une autre requête de création.

2. 2.

   Si la création a été interrompue, réutilisez son requestId

   Renvoyez la requête de tâche à l’identique avec le même requestId pour récupérer la tâche existante. Modifier les données de la tâche tout en réutilisant cet identifiant provoque un conflit. Consultez la récupération par identifiant de requête pour connaître l’ensemble des règles.

Les deux SDK génèrent un requestId s’il est omis et ne retentent jamais automatiquement la création. Leur SolvethreeError expose les identifiants de récupération : request_id et task_id en Python, ou requestId et taskId en JavaScript. Vérifiez ces champs avant de décider de créer une nouvelle tâche logique.

Une requête d’interrogation renvoie une erreur HTTP

Inspectez le statut HTTP séparément du statut de la tâche. ApiError du SDK expose ce statut ainsi que tout délai avant une nouvelle tentative.

Essayez ceci : Pour les échecs temporaires d’interrogation, respectez Retry-After dans la limite de l’échéance globale de résolution. Les champs du SDK sont retry_after en secondes en Python et retryAfterMs en millisecondes en JavaScript.

La tâche renvoie failed

Lisez errorCode et error ; le SDK représente cet état par TaskFailedError.

Essayez ceci : Arrêtez d’interroger cette tâche. Diagnostiquez la cause signalée avant d’en créer une autre ; ne réessayez pas aveuglément avec les mêmes données invalides et ne supposez pas que le problème vient du crédit.

La récupération renvoie HTTP 410

Le résultat stocké a expiré.

Essayez ceci : Cessez de retenter la récupération comme s’il s’agissait d’une erreur temporaire d’interrogation. Les résultats terminés ont une durée de conservation limitée et ne constituent pas un cache permanent de solutions.

Enregistrer une réponse prête ne prolonge pas la durée de vie du jeton ou du cookie de la cible.