Reprendre une requête ayant dépassé le délai sans payer une autre tâche

Un requestId identifie une même tâche logique sur plusieurs tentatives de création. Il accepte de 1 à 64 lettres ASCII, chiffres, traits de soulignement ou traits d’union. Choisissez-le avant d’envoyer la requête et conservez-le avec les données d’origine de la tâche.

1. 1.

   Enregistrez le corps de la tâche

   Placez la requête complète, y compris requestId, dans request.json. Pour reCAPTCHA Enterprise, incluez site sous forme de nom d’hôte, action, et exactement un des champs proxy ou proxyCandidates. N’ajoutez ni type ni url. Gardez ce fichier confidentiel, car il contient les identifiants du proxy.

2. 2.

   Envoyez le fichier enregistré

   Exécutez la commande ci-dessous avec la clé API de votre espace de travail. Conservez la clé sur le serveur.

3. 3.

   Si le délai de connexion est dépassé, répétez la commande

   Utilisez exactement la même commande et le fichier request.json inchangé. Ne générez pas un autre requestId et ne modifiez pas les données de la tâche simplement parce que la réponse n’est pas arrivée.

# request.json contains one valid task body and a saved requestId.
# Keep the file private: it contains your proxy credentials.
curl --fail-with-body --max-time 30 \
  'https://api.solvethree.com/v1/tasks?waitMs=0' \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY" \
  -H 'Content-Type: application/json' --data-binary @request.json

# If the connection broke, run the identical command with the identical file.
# New task: HTTP 201. Same requestId + same inputs: HTTP 200, existing task.
# Same requestId + changed inputs: HTTP 409.

HTTP 201 signifie qu’une nouvelle tâche a été créée. HTTP 200 signifie que la requête identique a permis de récupérer la tâche existante. Dans les deux cas, lisez l’identifiant et le statut de la tâche renvoyés ; aucun de ces statuts HTTP ne signifie à lui seul qu’une solution est prête.

Pour un exemple concret de modification des données, supposons que la requête enregistrée ait action défini sur login. Le remplacer par checkout tout en conservant le même requestId renvoie HTTP 409, un conflit d’identifiant de requête. Pour récupérer la tâche d’origine, restaurez le fichier d’origine et renvoyez-le. Si vous avez volontairement besoin des données modifiées, attribuez un nouveau requestId à cette nouvelle tâche logique.

Traitez les réponses HTTP qui n’indiquent pas un succès avant de lire les données de réussite d’une tâche. Un code 409 est une erreur de requête HTTP, pas un échec définitif de la tâche d’origine.

Les deux SDK officiels génèrent un requestId si vous l’omettez, mais aucun ne relance automatiquement la création d’une tâche. Si un appel au SDK lève une exception, examinez ses champs de récupération avant de lancer une autre tâche.

• JavaScript : SolvethreeError expose requestId et taskId.
• Python : SolvethreeError expose request_id et task_id.

Si l’erreur contient un identifiant de tâche, reprenez l’interrogation périodique par GET de cette tâche ; il n’est pas nécessaire de répéter la création. Si elle contient uniquement un identifiant de requête, relancez la création avec cet identifiant et les données d’origine, puis utilisez l’identifiant de tâche renvoyé. Il est important de conserver les données d’origine, même lorsque le SDK a généré l’identifiant.

Ne considérez pas chaque exception comme une interruption de création. TaskFailedError représente une tâche qui a déjà atteint un statut d’échec définitif, pas une requête à récupérer.

Récupérez la tâche avec GET /v1/tasks/:id. Continuez à l’interroger tant que son statut est pending ou solving. Seul ready contient une solution utilisable.

Si le statut est failed, arrêtez l’interrogation et examinez errorCode et error. Les résolutions échouées sont remboursées. Cela diffère du rejet d’une solution générée par un site web : ready signifie que la solution est disponible, pas que la cible l’a acceptée.

Les résultats des tâches terminées peuvent renvoyer HTTP 410 après l’expiration de leur durée de conservation ; la récupération ne constitue donc pas un stockage permanent des résultats. Pour la boucle d’interrogation elle-même, consultez l’interrogation des tâches et les délais d’attente.