Cancel local waiting with the Node.js SDK

Use the official JavaScript SDK on Node.js 22 or later, with your API key kept server-side. Replace the example hostname and action with your target values, configure an active site profile, and set the proxy environment variable.

The example generates a requestId before calling solve. Persist that ID and the unchanged task input before the call—not just in the error handler. Generating a fresh ID during recovery would lose the link to the original request.

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

The five-second timer calls abort; signal connects that controller to the SDK operation. The separate timeoutMs value sets the solve deadline to 180 seconds. Either can end the wait, so keep recovery information for both cases. The finally block clears the timer if the operation finishes first.

The catch block logs recovery IDs and rethrows the error; it doesn't resume the task. Your caller needs to retain those IDs and choose the appropriate recovery path.

• Terminal failure: Handle TaskFailedError first, as the example does. Inspect errorCode and the error message, then stop polling that failed task.
• Known task ID: If SolvethreeError.taskId is present, resume retrieval with getTask using that same ID. Don't call solve again merely to resume polling.
• No task ID: Recover creation by passing the saved, unchanged task to createTask with the same requestId. Use the error's requestId when available, falling back to the ID saved before the call. An interrupted connection doesn't prove creation failed.

Replaying identical inputs with the same requestId returns the existing task. Changing the inputs while reusing that ID conflicts, so don't change the proxy, hostname, or action during recovery.

When retrieving the task, pending and solving mean keep waiting within your chosen local limit. Only ready contains a usable solution. Stop on failed and inspect its error details.

1. 1.

   Save one test request

   Record the complete task input and its requestId before running the example. Keep those values for the entire test.

2. 2.

   Observe how the first call ends

   If the operation is still waiting when the five-second timer fires, capture the resulting error and recovery IDs. A ready result or terminal failure may arrive first; that run hasn't exercised cancellation.

3. 3.

   Resume the same task

   Use the recovery path above to obtain the task ID, then call getTask with that ID and waitMs set to 15000. Limit the number of retrieval attempts or set a local test deadline. If the task remains pending or solving when that limit is reached, retain its ID for a later resume rather than creating another task.

Check that recovery returns the original task ID whenever it was already known. This checks local cancellation and task recovery—not whether the target website accepts a resulting token.