Python-SDK-Fehler behandeln, ohne Lösungsvorgänge zu duplizieren

Die Methode solve des synchronen Python-SDKs erstellt einen Task einmal und fragt ihn ab, bis er bereit ist oder ein Fehler ausgelöst wird. Fangen Sie die spezifischen Ausnahmen vor SolvethreeError ab, damit Sie einen fehlgeschlagenen Lösevorgang von einer unterbrochenen HTTP-Anfrage unterscheiden können.

Setzen Sie SOLVETHREE_API_KEY und SOLVETHREE_PROXY und ersetzen Sie anschließend den Beispielhostnamen und die Aktion durch die Werte Ihres Ziels. Die Site benötigt ein aktives Workspace-Profil, bevor sie gelöst werden kann.

import os
import uuid
from solvethree import Solvethree, ApiError, TaskFailedError, SolvethreeError

client = Solvethree(os.environ["SOLVETHREE_API_KEY"])
task = {"site": "accounts.example.com", "action": "login", "proxy": os.environ["SOLVETHREE_PROXY"], "requestId": str(uuid.uuid4())}
try:
    result = client.solve(task, timeout=180)
    print("Ready task:", result["id"])
    # Submit result["solution"] privately through the target application.
except TaskFailedError as error:
    print("Failed task:", error.task_id, "code:", error.error_code)
    # This task is terminal. Inspect it before starting different work.
except ApiError as error:
    print("HTTP status:", error.status, "retry delay:", error.retry_after)
    print("Recovery IDs:", error.request_id, error.task_id)
    # A known task_id means resume get_task; otherwise replay the exact task
    # with error.request_id. Do not generate a new logical request to recover it.
except SolvethreeError as error:
    print("Recovery IDs:", error.request_id, error.task_id)
    # Save these IDs and the original task inputs for explicit recovery.

• TaskFailedError: Der Task hat den endgültigen Status failed erreicht. Prüfen Sie error.task_id und error.error_code; fragen Sie diesen Task nicht weiter ab.
• ApiError: Eine HTTP-Anfrage ist fehlgeschlagen. Prüfen Sie error.status und error.retry_after, dessen Wert in Sekunden angegeben wird. Das ist nicht dasselbe wie ein endgültiger Task-Fehler.
• SolvethreeError: Bewahren Sie error.request_id und error.task_id für eine explizite Wiederherstellung auf. Verwenden Sie die verfügbaren IDs, statt davon auszugehen, dass keine Erstellung stattgefunden hat.

Das Beispiel gibt Wiederherstellungsinformationen aus, speichert sie aber weder dauerhaft noch führt es eine Wiederherstellung durch. Speichern Sie in einer Integration, die einen Prozessneustart überstehen muss, die ursprünglichen Task-Eingaben und die Anfrage-ID vor dem Aufruf von solve und bewahren Sie anschließend jede zurückgegebene Task-ID auf. Schützen Sie gespeicherte Eingaben, die Proxy-Zugangsdaten enthalten.

1. 1.

   Wenn Sie eine task_id haben, setzen Sie get_task fort

   Rufen Sie diesen Task ab, statt solve erneut aufzurufen. get_task akzeptiert die Task-ID und ein Argument wait_ms; die Standardwartezeit beträgt 15000 Millisekunden. Fahren Sie fort, solange der Status pending oder solving ist. Verwenden Sie die Lösung nur im Status ready und stoppen Sie bei failed.

2. 2.

   Wenn die Erstellung unterbrochen wurde, bevor Sie eine Task-ID erhalten haben, senden Sie create_task erneut

   Senden Sie die identischen Task-Eingaben mit derselben requestId und verwenden Sie bei Bedarf die wiedergewonnene request_id. Wenn Sie diese ID mit derselben Anfrage wiederverwenden, wird der bestehende Task zurückgegeben; geänderte Eingaben führen zu einem Konflikt. Sobald Sie seine Task-ID haben, fahren Sie mit get_task fort.

3. 3.

   Bei der Wiederherstellung keine neue ID generieren

   Das Beispiel generiert seine UUID vor dem Aufruf von solve. Behalten Sie diesen Wert bei der Wiederherstellung bei; führen Sie die Task-Erstellung nicht erneut aus und ersetzen Sie ihn dadurch versehentlich. Eine neue ID steht für eine separate Anfrage, nicht für einen erneuten Versuch der unterbrochenen Anfrage.

Das SDK generiert eine requestId, wenn Sie sie weglassen, stellt Wiederherstellungs-IDs in Fehlern bereit und wiederholt die Task-Erstellung nie automatisch. Während solve berücksichtigt es Retry-After bei vorübergehenden Polling-Fehlern innerhalb der Frist für das Lösen. Wenn der Aufruf dennoch einen Fehler auslöst, verwenden Sie die gespeicherten IDs zum Fortsetzen, statt einen weiteren Lösevorgang zu starten.

Prüfen Sie bei ApiError den HTTP-Fehler, bevor Sie entscheiden, etwas erneut zu senden. Die Wiederherstellung einer unterbrochenen Erstellung ist sinnvoll, wenn der Ausgang ungewiss ist; unveränderte ungültige Eingaben blind erneut zu senden, ist es nicht.

Bei TaskFailedError ist der Task abgeschlossen. Ein abgerufener fehlgeschlagener Task enthält errorCode und error; die Python-Ausnahme stellt den Code als error.error_code bereit. Entscheiden Sie anhand dieser Informationen, was geändert werden muss. Beispielsweise erfordert site-unreachable eine Untersuchung der Erreichbarkeit des Ziels, statt anzunehmen, dass dem Konto Guthaben fehlt. Fehlgeschlagene Lösevorgänge werden erstattet.