Cancela la espera local con el SDK de Node.js

Usa el SDK oficial de JavaScript en Node.js 22 o posterior y mantén tu clave de API en el servidor. Sustituye el nombre de host y la acción del ejemplo por los valores de tu destino, configura un perfil de sitio activo y define la variable de entorno del proxy.

El ejemplo genera un requestId antes de llamar a solve. Guarda de forma persistente ese ID y la entrada de la tarea sin cambios antes de la llamada, no solo en el manejador de errores. Generar un ID nuevo durante la recuperación haría que se perdiera el vínculo con la solicitud original.

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); }

El temporizador de cinco segundos llama a abort; signal conecta ese controlador con la operación del SDK. El valor independiente de timeoutMs establece el plazo de resolución en 180 segundos. Cualquiera de los dos puede poner fin a la espera, así que conserva la información de recuperación para ambos casos. El bloque finally cancela el temporizador si la operación termina antes.

El bloque catch registra los ID de recuperación y vuelve a lanzar el error; no reanuda la tarea. El código que lo invoca debe conservar esos ID y elegir la vía de recuperación adecuada.

• Fallo terminal: Gestiona primero TaskFailedError, como hace el ejemplo. Inspecciona errorCode y el mensaje de error y deja de consultar esa tarea fallida.
• ID de tarea conocido: Si existe SolvethreeError.taskId, reanuda las consultas con getTask usando ese mismo ID. No vuelvas a llamar a solve solo para reanudar las consultas periódicas.
• Sin ID de tarea: Recupera la creación pasando a createTask la tarea guardada, sin cambios, con el mismo requestId. Usa el requestId del error cuando esté disponible y, en caso contrario, el ID guardado antes de la llamada. Una conexión interrumpida no demuestra que la creación haya fallado.

Repetir las mismas entradas con el mismo requestId devuelve la tarea existente. Cambiar las entradas y reutilizar ese ID genera un conflicto, así que no cambies el proxy, el nombre de host ni la acción durante la recuperación.

Al consultar la tarea, pending y solving indican que debes seguir esperando dentro del límite local que hayas elegido. Solo ready contiene una solución utilizable. Detente si el estado es failed e inspecciona los detalles del error.

1. 1.

   Guarda una solicitud de prueba

   Registra la entrada completa de la tarea y su requestId antes de ejecutar el ejemplo. Conserva esos valores durante toda la prueba.

2. 2.

   Observa cómo termina la primera llamada

   Si la operación sigue esperando cuando se activa el temporizador de cinco segundos, captura el error resultante y los ID de recuperación. Puede que antes llegue un resultado listo o un fallo terminal; en ese caso, esa ejecución no ha probado la cancelación.

3. 3.

   Reanuda la misma tarea

   Usa la vía de recuperación anterior para obtener el ID de tarea y luego llama a getTask con ese ID y waitMs establecido en 15000. Limita el número de intentos de consulta o establece un plazo límite local para la prueba. Si la tarea sigue en pending o solving al alcanzar ese límite, conserva su ID para reanudarla más adelante en lugar de crear otra tarea.

Comprueba que la recuperación devuelva el ID de tarea original siempre que ya se conociera. Esto comprueba la cancelación local y la recuperación de la tarea, no si el sitio web de destino acepta el token resultante.