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.

   テストリクエストを1つ保存する

   例を実行する前に、タスク入力全体とその requestId を記録してください。テスト全体を通じてこれらの値を保持します。

2. 2.

   最初の呼び出しがどう終了するかを確認する

   5秒のタイマーが発火した時点でも処理が待機中なら、発生したエラーと復旧用 ID を記録してください。ready の結果や終端的な失敗が先に返る場合もあります。その実行では、キャンセルはテストできていません。

3. 3.

   同じタスクを再開する

   上記の復旧方法でタスク ID を取得し、その ID と 15000 に設定した waitMs で getTask を呼び出してください。取得の試行回数を制限するか、ローカルのテスト期限を設定します。その制限に達してもタスクが pending または solving のままなら、別のタスクを作成せず、後で再開できるよう ID を保持してください。

元のタスク ID がすでに判明している場合は、復旧でその ID が返されることを確認してください。これはローカルのキャンセルとタスクの復旧を確認するものであり、生成されたトークンを対象サイトが受け入れるかどうかを確認するものではありません。