Node.js SDK에서 로컬 대기 취소하기

Node.js 22 이상에서 공식 JavaScript SDK를 사용하고 API 키는 서버 측에 보관하세요. 예제의 호스트 이름과 액션을 대상 값으로 바꾸고, 활성 사이트 프로필을 구성하고, 프록시 환경 변수를 설정하세요.

이 예제는 solve를 호출하기 전에 requestId를 생성합니다. 오류 핸들러에서만 저장하지 말고, 호출 전에 해당 ID와 변경하지 않은 작업 입력을 영구 저장하세요. 복구 중에 새 ID를 생성하면 원래 요청과의 연결이 끊어집니다.

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

5초 타이머가 abort를 호출하고, signal은 해당 컨트롤러를 SDK 작업에 연결합니다. 별도의 timeoutMs 값은 풀이 제한 시간을 180초로 설정합니다. 둘 중 어느 쪽이든 대기를 끝낼 수 있으므로 두 경우 모두에 대비해 복구 정보를 보관하세요. 작업이 먼저 끝나면 finally 블록이 타이머를 해제합니다.

catch 블록은 복구 ID를 기록하고 오류를 다시 던질 뿐, 작업을 재개하지는 않습니다. 호출자는 해당 ID를 보관하고 적절한 복구 경로를 선택해야 합니다.

• 최종 실패: 예제처럼 TaskFailedError를 먼저 처리하세요. errorCode와 오류 메시지를 확인한 다음 실패한 작업의 폴링을 중단하세요.
• 작업 ID를 아는 경우: SolvethreeError.taskId가 있으면 동일한 ID로 getTask를 사용해 조회를 재개하세요. 단순히 폴링을 재개하기 위해 solve를 다시 호출하지 마세요.
• 작업 ID가 없는 경우: 저장해 둔 변경되지 않은 작업을 같은 requestId와 함께 createTask에 전달해 생성을 복구하세요. 오류에 requestId가 있으면 그 값을 사용하고, 없으면 호출 전에 저장한 ID를 사용하세요. 연결이 끊겼다고 해서 생성이 실패한 것은 아닙니다.

같은 requestId로 동일한 입력을 다시 보내면 기존 작업이 반환됩니다. 해당 ID를 재사용하면서 입력을 바꾸면 충돌이 발생하므로 복구 중에는 프록시, 호스트 이름, 액션을 변경하지 마세요.

작업 조회 시 pending과 solving은 설정한 로컬 제한 내에서 계속 기다려야 함을 의미합니다. 사용할 수 있는 솔루션은 ready에만 포함됩니다. failed이면 중단하고 오류 세부 정보를 확인하세요.

1. 1.

   테스트 요청 하나 저장

   예제를 실행하기 전에 전체 작업 입력과 requestId를 기록하세요. 테스트가 끝날 때까지 해당 값을 보관하세요.

2. 2.

   첫 호출이 어떻게 끝나는지 관찰

   5초 타이머가 실행될 때까지 작업이 대기 중이면 발생한 오류와 복구 ID를 수집하세요. ready 결과나 최종 실패가 먼저 도착할 수도 있으며, 그런 실행에서는 취소가 테스트되지 않은 것입니다.

3. 3.

   동일한 작업 재개

   위의 복구 경로로 작업 ID를 확보한 다음, 해당 ID와 15000으로 설정한 waitMs를 사용해 getTask를 호출하세요. 조회 시도 횟수를 제한하거나 로컬 테스트 제한 시간을 설정하세요. 제한에 도달했을 때 작업이 여전히 pending 또는 solving이면 다른 작업을 생성하지 말고 나중에 재개할 수 있도록 ID를 보관하세요.

원래 작업 ID를 이미 알고 있었다면 복구 시 그 ID가 반환되는지 확인하세요. 이 과정은 로컬 취소와 작업 복구를 검증하는 것이지, 대상 웹사이트가 결과 토큰을 수락하는지를 검증하는 것은 아닙니다.