Polling und Zeitüberschreitungen bei CAPTCHA-Aufgaben behandeln

waitMs steuert, wie lange eine API-Anfrage auf ein Ergebnis wartet, bevor sie antwortet. Es ist ein URL-Abfrageparameter, kein Feld im Aufgaben-JSON. Die Standardwerte bei der Erstellung unterscheiden sich je nach Produkt; GET-Polling hat ein eigenes Limit.

Geben Sie dem HTTP-Client genügend Zeit für die angeforderte Serverwartezeit zuzüglich Netzwerk-Overhead. Ein Client-Timeout, das kürzer als die Serverwartezeit ist, kann die Antwort unterbrechen, bevor Sie den aktuellen Aufgabenstatus erhalten.

Die Methode solve der offiziellen SDKs erstellt die Aufgabe einmal und fragt ihren Status bis zu einem fertigen Ergebnis oder einem Fehler ab. Python bietet timeout in Sekunden und poll_interval in Sekunden; Node.js bietet timeoutMs und pollIntervalMs in Millisekunden. Die dokumentierten Einstellungen verwenden ein Zeitlimit von drei Minuten für den Lösungsvorgang und ein Polling-Intervall von einer Sekunde.

Für direkte Kontrolle bietet Python create_task und get_task; Node.js bietet createTask und getTask. Gehen Sie wie folgt vor:

1. 1.

   Zeitlimit festlegen und eine Aufgabe erstellen

   Legen Sie vor der Erstellung ein Gesamtzeitlimit fest. Bewahren Sie eine requestId zusammen mit den exakten Aufgabeneingaben auf, damit Sie eine unterbrochene Erstellung wiederaufnehmen können. Um während der Erstellung nicht zu warten, wählen Sie explizit eine Wartezeit von null.

2. 2.

   Zurückgegebene Aufgaben-ID speichern und Status prüfen

   Bereits die Erstellung kann ein endgültiges Ergebnis zurückgeben. Geben Sie bei ready die Lösung zurück. Prüfen Sie bei failed errorCode und error und brechen Sie ab; fehlgeschlagene Lösungsversuche werden erstattet. Nur pending und solving erfordern weiteres Polling.

3. 3.

   Dieselbe Aufgabe abrufen, solange Zeit verbleibt

   Verwenden Sie GET /v1/tasks/:id, optional mit einer Long-Poll-Wartezeit von bis zu 15000 ms. Behandeln Sie nicht erfolgreiche HTTP-Antworten, bevor Sie eine Erfolgs-Nutzlast lesen. Wenn die Antwort weiterhin pending oder solving angibt, wiederholen Sie die Abfrage mit derselben ID – erstellen Sie keine weitere Aufgabe.

4. 4.

   Beim Erreichen des Zeitlimits stoppen

   Begrenzen Sie jede Anfrage auf die verbleibende Zeit und berücksichtigen Sie dabei den Netzwerk-Overhead. Wenn Ihr Zeitlimit abläuft, beenden Sie die lokale Schleife und bewahren Sie die Aufgaben-ID für die Wiederaufnahme auf. Kennzeichnen Sie die Aufgabe nicht als fehlgeschlagen, nur weil Ihr Client nicht mehr wartet.

Diese Anfrage ruft eine bestehende Aufgabe ab und erlaubt eine Serverwartezeit von 15 Sekunden sowie ein Client-Timeout von 30 Sekunden. Setzen Sie TASK_ID auf die gespeicherte ID und bewahren Sie SOLVETHREE_API_KEY auf dem Server auf. Keines der beiden Timeouts ist ein Gesamtzeitlimit für eine wiederholte Polling-Schleife.

curl --fail-with-body --max-time 30 \
  "https://api.solvethree.com/v1/tasks/$TASK_ID?waitMs=15000" \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY"

Eine erfolgreiche HTTP-Antwort kann eine Aufgabe enthalten, die weiterhin Polling erfordert. pending und solving sind keine Endzustände; nur ready enthält eine verwendbare Lösung. failed ist ein Endzustand und enthält errorCode und error.

{
  "nonterminal": [
    {
      "id": "example-task",
      "status": "pending"
    },
    {
      "id": "example-task",
      "status": "solving"
    }
  ],
  "ready": {
    "id": "example-task",
    "status": "ready",
    "solution": {
      "token": "EXAMPLE_TOKEN",
      "userAgent": "EXAMPLE_USER_AGENT",
      "secChUa": "EXAMPLE_CLIENT_HINTS"
    }
  },
  "failed": {
    "id": "example-task",
    "status": "failed",
    "errorCode": "site-unreachable",
    "error": "target page did not respond"
  }
}

Die hier gezeigte ready-Antwort enthält einen reCAPTCHA-Token. Kasada gibt stattdessen Header zurück und TMPT einen unverarbeiteten Cookie-Wert. Ein fertiges Ergebnis bedeutet, dass eine Lösung erzeugt wurde – nicht, dass das nachgelagerte Ziel sie akzeptiert hat. Wenn ein fertiger reCAPTCHA-Token abgelehnt wird, wechseln Sie von der Polling-Diagnose zur Prüfung des übermittelten Tokens.

Eine Verbindungszeitüberschreitung zeigt an, dass der Client keine vollständige Antwort erhalten hat. Sie beweist nicht, dass die Erstellung fehlgeschlagen ist. Bevor Sie für einen weiteren Lösungsversuch bezahlen, nehmen Sie die Aufgabe wieder auf, die Sie möglicherweise bereits erstellt haben.

1. 1.

   Mit vorhandener Aufgaben-ID das GET-Polling fortsetzen

   Rufen Sie diese ID mit einem neuen, begrenzten lokalen Zeitlimit ab. Eine Zeitüberschreitung bei GET ist kein Grund, eine weitere Erstellungsanfrage zu senden.

2. 2.

   Bei unterbrochener Erstellung dieselbe requestId erneut verwenden

   Senden Sie die identische Aufgabenanfrage mit derselben requestId erneut, um die bestehende Aufgabe wiederaufzunehmen. Geänderte Aufgabeneingaben bei Wiederverwendung dieser ID führen zu einem Konflikt. Die vollständigen Regeln finden Sie unter Wiederaufnahme per Anfrage-ID.

Beide SDKs erzeugen eine requestId, wenn sie nicht angegeben wird, und wiederholen die Erstellung niemals automatisch. Ihr SolvethreeError stellt IDs zur Wiederaufnahme bereit: request_id und task_id in Python oder requestId und taskId in JavaScript. Prüfen Sie diese Felder, bevor Sie entscheiden, eine neue logische Aufgabe zu erstellen.

Eine Polling-Anfrage gibt einen HTTP-Fehler zurück

Prüfen Sie den HTTP-Status getrennt vom Aufgabenstatus. ApiError des SDKs stellt diesen Status und eine gegebenenfalls vorhandene Wartezeit bis zum nächsten Versuch bereit.

Probiere Folgendes: Beachten Sie bei vorübergehenden Polling-Fehlern Retry-After innerhalb des Gesamtzeitlimits für den Lösungsvorgang. Die SDK-Felder sind retry_after in Python mit Sekunden und retryAfterMs in JavaScript mit Millisekunden.

Die Aufgabe gibt failed zurück

Lesen Sie errorCode und error; das SDK stellt dies als TaskFailedError dar.

Probiere Folgendes: Beenden Sie das Polling dieser Aufgabe. Diagnostizieren Sie die gemeldete Ursache, bevor Sie eine weitere erstellen; wiederholen Sie nicht blind unveränderte ungültige Eingaben und gehen Sie nicht davon aus, dass das Guthaben das Problem ist.

Der Abruf gibt HTTP 410 zurück

Das gespeicherte Ergebnis ist abgelaufen.

Probiere Folgendes: Wiederholen Sie den Abruf nicht weiter, als wäre dies ein vorübergehender Polling-Fehler. Abgeschlossene Ergebnisse werden nur begrenzt aufbewahrt und sind kein dauerhafter Lösungscache.

Das Speichern einer ready-Antwort verlängert nicht die Gültigkeitsdauer des Tokens oder Cookies beim Ziel.