Lokales Warten mit dem Node.js SDK abbrechen

Verwenden Sie das offizielle JavaScript-SDK unter Node.js 22 oder höher und bewahren Sie Ihren API-Schlüssel serverseitig auf. Ersetzen Sie den Beispielhostnamen und die Beispielaktion durch Ihre Zielwerte, konfigurieren Sie ein aktives Website-Profil und setzen Sie die Proxy-Umgebungsvariable.

Das Beispiel erzeugt vor dem Aufruf von solve eine requestId. Speichern Sie diese ID und die unveränderte Aufgabeneingabe vor dem Aufruf dauerhaft – nicht erst im Fehlerhandler. Wenn Sie bei der Wiederherstellung eine neue ID erzeugen, geht die Zuordnung zur ursprünglichen Anfrage verloren.

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

Der Timer ruft nach fünf Sekunden abort auf; signal verbindet diesen Controller mit dem SDK-Vorgang. Der separate Wert timeoutMs setzt die Zeitgrenze für die Lösung auf 180 Sekunden. Beides kann das Warten beenden, bewahren Sie daher für beide Fälle die Wiederherstellungsinformationen auf. Der finally-Block löscht den Timer, wenn der Vorgang vorher abgeschlossen wird.

Der catch-Block protokolliert die Wiederherstellungs-IDs und wirft den Fehler erneut; er setzt die Aufgabe nicht fort. Ihr Aufrufer muss diese IDs aufbewahren und den passenden Wiederherstellungsweg wählen.

• Endgültiger Fehler: Behandeln Sie wie im Beispiel zuerst TaskFailedError. Prüfen Sie errorCode und die Fehlermeldung und beenden Sie dann das Polling dieser fehlgeschlagenen Aufgabe.
• Bekannte Aufgaben-ID: Wenn SolvethreeError.taskId vorhanden ist, setzen Sie den Abruf mit getTask und derselben ID fort. Rufen Sie nicht erneut solve auf, nur um das Polling fortzusetzen.
• Keine Aufgaben-ID: Stellen Sie die Erstellung wieder her, indem Sie die gespeicherte, unveränderte Aufgabe mit derselben requestId an createTask übergeben. Verwenden Sie die requestId des Fehlers, falls verfügbar, andernfalls die vor dem Aufruf gespeicherte ID. Eine unterbrochene Verbindung beweist nicht, dass die Erstellung fehlgeschlagen ist.

Wenn Sie identische Eingaben mit derselben requestId erneut senden, wird die bestehende Aufgabe zurückgegeben. Geänderte Eingaben bei Wiederverwendung dieser ID führen zu einem Konflikt. Ändern Sie daher bei der Wiederherstellung weder Proxy noch Hostnamen oder Aktion.

Beim Abrufen der Aufgabe bedeuten pending und solving, dass Sie innerhalb Ihrer gewählten lokalen Zeitgrenze weiter warten sollten. Nur ready enthält eine nutzbare Lösung. Stoppen Sie bei failed und prüfen Sie die Fehlerdetails.

1. 1.

   Eine Testanfrage speichern

   Speichern Sie die vollständige Aufgabeneingabe und ihre requestId, bevor Sie das Beispiel ausführen. Bewahren Sie diese Werte während des gesamten Tests auf.

2. 2.

   Beobachten, wie der erste Aufruf endet

   Wenn der Vorgang noch wartet, wenn der Timer nach fünf Sekunden auslöst, erfassen Sie den daraus entstehenden Fehler und die Wiederherstellungs-IDs. Ein fertiges Ergebnis oder ein endgültiger Fehler kann früher eintreffen; in diesem Durchlauf wurde der Abbruch dann nicht getestet.

3. 3.

   Dieselbe Aufgabe fortsetzen

   Ermitteln Sie die Aufgaben-ID über den oben beschriebenen Wiederherstellungsweg und rufen Sie dann getTask mit dieser ID und waitMs auf 15000 auf. Begrenzen Sie die Anzahl der Abrufversuche oder setzen Sie eine lokale Zeitgrenze für den Test. Wenn die Aufgabe beim Erreichen dieser Grenze weiterhin pending oder solving ist, bewahren Sie ihre ID für eine spätere Fortsetzung auf, statt eine weitere Aufgabe zu erstellen.

Prüfen Sie, ob die Wiederherstellung die ursprüngliche Aufgaben-ID zurückgibt, sofern diese bereits bekannt war. Damit prüfen Sie den lokalen Abbruch und die Wiederherstellung der Aufgabe – nicht, ob die Zielwebsite ein daraus resultierendes Token akzeptiert.