Eine Anfrage nach Zeitüberschreitung wiederaufnehmen, ohne für eine weitere Aufgabe zu bezahlen

Eine requestId identifiziert eine logische Aufgabe über mehrere Erstellungsversuche hinweg. Zulässig sind 1–64 ASCII-Buchstaben, Ziffern, Unterstriche oder Bindestriche. Wählen Sie sie vor dem Senden der Anfrage und bewahren Sie sie zusammen mit den ursprünglichen Aufgabeneingaben auf.

1. 1.

   Aufgaben-Body speichern

   Speichern Sie die vollständige Anfrage einschließlich requestId in request.json. Geben Sie für reCAPTCHA Enterprise site als Hostnamen, action und genau eines der Felder proxy oder proxyCandidates an. Fügen Sie weder type noch url hinzu. Halten Sie die Datei privat, da sie Proxy-Zugangsdaten enthält.

2. 2.

   Gespeicherte Datei senden

   Führen Sie den folgenden Befehl mit dem API-Schlüssel Ihres Workspace aus. Bewahren Sie den Schlüssel auf dem Server auf.

3. 3.

   Bei einem Verbindungs-Timeout den Befehl wiederholen

   Verwenden Sie denselben Befehl und die unveränderte Datei request.json. Generieren Sie keine weitere requestId und ändern Sie die Aufgabeneingaben nicht, nur weil die Antwort nicht angekommen ist.

# request.json contains one valid task body and a saved requestId.
# Keep the file private: it contains your proxy credentials.
curl --fail-with-body --max-time 30 \
  'https://api.solvethree.com/v1/tasks?waitMs=0' \
  -H "Authorization: Bearer $SOLVETHREE_API_KEY" \
  -H 'Content-Type: application/json' --data-binary @request.json

# If the connection broke, run the identical command with the identical file.
# New task: HTTP 201. Same requestId + same inputs: HTTP 200, existing task.
# Same requestId + changed inputs: HTTP 409.

HTTP 201 bedeutet, dass eine neue Aufgabe erstellt wurde. HTTP 200 bedeutet, dass die identische Anfrage die bestehende Aufgabe wiederhergestellt hat. Lesen Sie in beiden Fällen die zurückgegebene Aufgaben-ID und den Status aus; keiner der beiden HTTP-Status bedeutet allein, dass eine Lösung bereitsteht.

Ein konkretes Beispiel für geänderte Eingaben: Angenommen, in der gespeicherten Anfrage ist action auf login gesetzt. Wenn Sie den Wert zu checkout ändern und dieselbe requestId beibehalten, wird HTTP 409 zurückgegeben: ein Anfrage-ID-Konflikt. Um die ursprüngliche Aufgabe wiederherzustellen, stellen Sie die ursprüngliche Datei wieder her und senden Sie sie erneut. Wenn Sie die geänderten Eingaben bewusst benötigen, geben Sie dieser neuen logischen Aufgabe eine neue requestId.

Behandeln Sie HTTP-Antworten ohne Erfolgsstatus, bevor Sie die Erfolgsdaten einer Aufgabe auslesen. Ein 409 ist ein HTTP-Anfragefehler, kein endgültiger Fehler der ursprünglichen Aufgabe.

Beide offiziellen SDKs generieren eine requestId, wenn Sie keine angeben. Keines wiederholt jedoch die Aufgabenerstellung automatisch. Wenn ein SDK-Aufruf eine Ausnahme auslöst, prüfen Sie dessen Wiederherstellungsfelder, bevor Sie eine weitere Aufgabe starten.

• JavaScript: SolvethreeError stellt requestId und taskId bereit.
• Python: SolvethreeError stellt request_id und task_id bereit.

Wenn der Fehler eine Aufgaben-ID enthält, setzen Sie das GET-Polling für diese Aufgabe fort; die Erstellung muss nicht wiederholt werden. Enthält er nur eine Anfrage-ID, wiederholen Sie die Erstellung mit dieser ID und den ursprünglichen Eingaben und verwenden Sie dann die zurückgegebene Aufgaben-ID. Die ursprünglichen Eingaben müssen auch dann erhalten bleiben, wenn das SDK die ID generiert hat.

Behandeln Sie nicht jede Ausnahme als unterbrochene Erstellung. TaskFailedError steht für eine Aufgabe, die bereits den endgültigen Fehlerstatus erreicht hat, nicht für eine Anfrage, die wiederhergestellt werden muss.

Rufen Sie die wiederhergestellte Aufgabe mit GET /v1/tasks/:id ab. Setzen Sie das Polling fort, solange ihr Status pending oder solving ist. Nur ready enthält eine verwendbare Lösung.

Wenn der Status failed ist, beenden Sie das Polling und prüfen Sie errorCode und error. Fehlgeschlagene Lösungsvorgänge werden erstattet. Das unterscheidet sich davon, dass eine Website eine generierte Lösung ablehnt: ready bedeutet, dass die Lösung verfügbar ist, nicht, dass das Ziel sie akzeptiert hat.

Nach Ablauf der Aufbewahrungsfrist können abgeschlossene Ergebnisse HTTP 410 zurückgeben. Die Wiederherstellung ist daher kein dauerhafter Ergebnisspeicher. Zur Polling-Schleife selbst siehe Aufgaben-Polling und Timeouts.