Annuler l’attente locale avec le SDK Node.js

Utilisez le SDK JavaScript officiel avec Node.js 22 ou version ultérieure, en conservant votre clé API côté serveur. Remplacez le nom d’hôte et l’action de l’exemple par vos valeurs cibles, configurez un profil de site actif et définissez la variable d’environnement du proxy.

L’exemple génère un requestId avant d’appeler solve. Enregistrez durablement cet ID et les données d’entrée inchangées de la tâche avant l’appel, pas seulement dans le gestionnaire d’erreurs. Générer un nouvel ID lors de la récupération ferait perdre le lien avec la requête d’origine.

import { randomUUID } from 'node:crypto';
import { Solvethree, SolvethreeError, TaskFailedError } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
const task = { site: 'accounts.example.com', action: 'login', proxy: process.env.SOLVETHREE_PROXY, requestId: randomUUID() };
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 5000);
try {
  const result = await client.solve(task, { signal: controller.signal, timeoutMs: 180000 });
  console.log('Ready task:', result.id);
  // Submit this result with its browser identity and original proxy.
} catch (error) {
  if (error instanceof TaskFailedError) {
    console.error('Failed task:', error.taskId, error.errorCode);
  } else if (error instanceof SolvethreeError) {
    console.error('Recovery IDs:', error.requestId ?? task.requestId, error.taskId);
    // If taskId exists, retrieve it. Otherwise replay the unchanged task with
    // this requestId. Canceling local waiting did not cancel the remote task.
  }
  throw error;
} finally { clearTimeout(timer); }

Le minuteur de cinq secondes appelle abort ; signal relie ce contrôleur à l’opération du SDK. La valeur distincte timeoutMs fixe le délai de résolution à 180 secondes. L’un comme l’autre peut mettre fin à l’attente : conservez donc les informations de récupération pour les deux cas. Le bloc finally supprime le minuteur si l’opération se termine avant.

Le bloc catch journalise les ID de récupération et relance l’erreur ; il ne reprend pas la tâche. Le code appelant doit conserver ces ID et choisir la méthode de récupération appropriée.

• Échec terminal : Traitez d’abord TaskFailedError, comme dans l’exemple. Examinez errorCode et le message d’erreur, puis arrêtez d’interroger cette tâche en échec.
• ID de tâche connu : Si SolvethreeError.taskId est présent, reprenez la récupération avec getTask en utilisant ce même ID. Ne rappelez pas solve simplement pour reprendre l’interrogation.
• Aucun ID de tâche : Récupérez le résultat de la création en passant la tâche enregistrée et inchangée à createTask avec le même requestId. Utilisez le requestId de l’erreur s’il est disponible, sinon l’ID enregistré avant l’appel. Une connexion interrompue ne prouve pas que la création a échoué.

Renvoyer des entrées identiques avec le même requestId renvoie la tâche existante. Modifier les entrées tout en réutilisant cet ID provoque un conflit : ne changez donc pas le proxy, le nom d’hôte ni l’action lors de la récupération.

Lors de la récupération de la tâche, pending et solving indiquent qu’il faut continuer à attendre dans la limite locale choisie. Seul ready contient une solution utilisable. Arrêtez-vous sur failed et examinez les détails de l’erreur.

1. 1.

   Enregistrez une requête de test

   Enregistrez les données d’entrée complètes de la tâche et son requestId avant d’exécuter l’exemple. Conservez ces valeurs pendant tout le test.

2. 2.

   Observez comment le premier appel se termine

   Si l’opération est toujours en attente lorsque le minuteur de cinq secondes se déclenche, capturez l’erreur obtenue et les ID de récupération. Un résultat prêt ou un échec terminal peut arriver avant ; cette exécution n’a alors pas testé l’annulation.

3. 3.

   Reprenez la même tâche

   Utilisez la méthode de récupération ci-dessus pour obtenir l’ID de tâche, puis appelez getTask avec cet ID et waitMs défini sur 15000. Limitez le nombre de tentatives de récupération ou fixez une échéance locale pour le test. Si la tâche reste au statut pending ou solving lorsque cette limite est atteinte, conservez son ID pour la reprendre plus tard au lieu de créer une autre tâche.

Vérifiez que la récupération renvoie l’ID de tâche d’origine chaque fois qu’il était déjà connu. Cela vérifie l’annulation locale et la récupération de la tâche, pas l’acceptation d’un jeton obtenu par le site cible.