Cancele a espera local com o SDK de Node.js

Use o SDK JavaScript oficial no Node.js 22 ou posterior, mantendo sua chave de API no servidor. Substitua o hostname e a ação do exemplo pelos valores do seu destino, configure um perfil de site ativo e defina a variável de ambiente do proxy.

O exemplo gera um requestId antes de chamar solve. Persista esse ID e a entrada da tarefa sem alterações antes da chamada — não apenas no tratador de erros. Gerar um novo ID durante a recuperação perderia o vínculo com a solicitação 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); }

O temporizador de cinco segundos chama abort; signal conecta esse controlador à operação do SDK. O valor separado de timeoutMs define o prazo limite da resolução em 180 segundos. Qualquer um deles pode encerrar a espera, portanto guarde as informações de recuperação para ambos os casos. O bloco finally limpa o temporizador se a operação terminar primeiro.

O bloco catch registra os IDs de recuperação e relança o erro; ele não retoma a tarefa. O código chamador precisa guardar esses IDs e escolher o caminho de recuperação adequado.

• Falha terminal: Trate TaskFailedError primeiro, como faz o exemplo. Examine errorCode e a mensagem de erro e pare de consultar essa tarefa que falhou.
• ID de tarefa conhecido: Se SolvethreeError.taskId estiver presente, retome a consulta com getTask usando esse mesmo ID. Não chame solve novamente apenas para retomar as consultas periódicas.
• Sem ID de tarefa: Recupere a criação passando a tarefa salva, sem alterações, para createTask com o mesmo requestId. Use o requestId do erro quando disponível; caso contrário, use o ID salvo antes da chamada. Uma conexão interrompida não comprova que a criação falhou.

Reenviar entradas idênticas com o mesmo requestId retorna a tarefa existente. Alterar as entradas ao reutilizar esse ID gera conflito, portanto não altere o proxy, o hostname ou a ação durante a recuperação.

Ao consultar a tarefa, pending e solving indicam que você deve continuar esperando dentro do limite local escolhido. Apenas ready contém uma solução utilizável. Pare em failed e examine os detalhes do erro.

1. 1.

   Salve uma solicitação de teste

   Registre a entrada completa da tarefa e seu requestId antes de executar o exemplo. Guarde esses valores durante todo o teste.

2. 2.

   Observe como a primeira chamada termina

   Se a operação ainda estiver aguardando quando o temporizador de cinco segundos disparar, capture o erro resultante e os IDs de recuperação. Um resultado pronto ou uma falha terminal pode chegar primeiro; nesse caso, essa execução não testou o cancelamento.

3. 3.

   Retome a mesma tarefa

   Use o caminho de recuperação acima para obter o ID da tarefa e então chame getTask com esse ID e waitMs definido como 15000. Limite o número de tentativas de consulta ou defina um prazo limite local para o teste. Se a tarefa continuar em pending ou solving quando esse limite for atingido, guarde seu ID para retomá-la depois, em vez de criar outra tarefa.

Verifique se a recuperação retorna o ID original da tarefa sempre que ele já era conhecido. Isso verifica o cancelamento local e a recuperação da tarefa — não se o site de destino aceita um token resultante.