Go-SDK-Fehler behandeln und unterbrochene Aufgaben wiederherstellen

Verwenden Sie Go 1.22 oder neuer mit dem offiziellen Modul solvethree.com/sdk in Version v0.1.0. Hinweise zur Einrichtung finden Sie in der Anleitung zur Go-Integration.

Setzen Sie die serverseitigen Umgebungsvariablen SOLVETHREE_API_KEY und SOLVETHREE_PROXY. Ersetzen Sie Site und Action im Beispiel durch Ihren Zielhostnamen und Ihre Aktion. Die Website benötigt ein aktives Profil in Ihrem Workspace; durch Senden ihres Hostnamens wird keines erstellt. Diese reCAPTCHA-Anfrage verwendet einen einzelnen Proxy und benötigt weder Type noch URL.

package main

import (
    "context"
    "fmt"
    "errors"
    "log"
    "os"
    "time"
    solvethree "solvethree.com/sdk"
)

func main() {
    client, err := solvethree.NewClient(os.Getenv("SOLVETHREE_API_KEY"), nil)
    if err != nil { log.Fatal(err) }
    ctx, cancel := context.WithTimeout(context.Background(), 180*time.Second)
    defer cancel()
    input := solvethree.TaskRequest{Site: "accounts.example.com", Action: "login", Proxy: os.Getenv("SOLVETHREE_PROXY")}
    result, err := client.Solve(ctx, input, solvethree.SolveOptions{})
    if err != nil {
        var failed *solvethree.TaskFailedError
        var api *solvethree.APIError
        var recovery *solvethree.Error
        switch {
        case errors.As(err, &failed):
            log.Printf("Failed task %s: %s", failed.TaskID, failed.ErrorCode)
        case errors.As(err, &recovery):
            log.Printf("Recovery request=%s task=%s", recovery.RequestID, recovery.TaskID)
            if errors.As(err, &api) { log.Printf("HTTP %d; retry delay %s", api.StatusCode, api.RetryAfter) }
            // Save input plus recovery.RequestID. Resume GetTask for a known TaskID;
            // otherwise replay CreateTask with identical inputs and that RequestID.
        }
        return
    }
    fmt.Println("Ready task:", result.ID)
    // Submit result.Solution.Token with its browser identity and original proxy.
}

Das Beispiel setzt eine Kontextfrist von 180 Sekunden und protokolliert IDs für die Wiederaufnahme, wenn ein SDK-Fehler sie bereitstellt. Protokollierung allein ermöglicht keine dauerhafte Wiederaufnahme: Speichern Sie die ursprüngliche input, die zurückgegebene RequestID und jede vorhandene TaskID, bevor Sie den Fehler verwerfen.

„Fertige Aufgabe“ bedeutet, dass eine Lösung verfügbar ist, nicht, dass das Ziel sie akzeptiert hat. Das SDK übermittelt sie nicht für Sie. Übermitteln Sie Solution.Token mit der zurückgegebenen Browseridentität und bei diesem Beispiel mit einem einzelnen Proxy über den ursprünglichen Proxy.

Untersuchen Sie umschlossene Fehler mit errors.As und Abbrüche mit errors.Is. Diese Prüfungen beantworten unterschiedliche Fragen: Ein Fehler kann IDs für die Wiederaufnahme enthalten, einen HTTP-Fehler umschließen und dennoch als unterbrochener Vorgang behandelt werden müssen.

Das Beispiel prüft innerhalb seines Wiederaufnahmezweigs auf einen verschachtelten APIError. Prüfen Sie den Abbruch separat mit errors.Is, wenn Ihre Anwendung zwischen einer abgelaufenen Frist und einem ausdrücklichen Abbruch unterscheiden muss.

Solve erstellt die Aufgabe einmal. Es wiederholt nur Polling-Anfragen bei temporären Antworten mit HTTP 429, 502, 503 oder 504 und berücksichtigt dabei Retry-After innerhalb der Kontextfrist. CreateTask wiederholt seinen POST niemals automatisch.

1. 1.

   Ursprüngliche Anfrage unverändert aufbewahren

   Speichern Sie alle Aufgabeneingaben, einschließlich des Proxys oder der Kandidatenliste, zusammen mit der Anfrage-ID. CreateTask generiert eine Anfrage-ID, wenn Sie keine angeben; erfassen Sie den generierten Wert, den der Fehler zur Wiederaufnahme bereitstellt. Rekonstruieren Sie die Anfrage später nicht aus einer Konfiguration, die sich möglicherweise geändert hat.

2. 2.

   GetTask verwenden, wenn die Aufgaben-ID bekannt ist

   Erstellen Sie einen neuen Kontext, wenn der alte abgelaufen ist oder abgebrochen wurde, und rufen Sie anschließend die gespeicherte TaskID mit GetTask ab. Warten Sie bei pending oder solving weiter, verwenden Sie die Lösung nur bei ready und beenden Sie den Vorgang bei failed.

3. 3.

   Erstellung nur wiederholen, wenn die Aufgaben-ID unbekannt ist

   Setzen Sie RequestID in der gespeicherten ursprünglichen TaskRequest auf die wiedergewonnene Anfrage-ID und rufen Sie dann CreateTask mit denselben Eingaben auf. Die Wiederverwendung derselben ID und Anfrage gibt die vorhandene Aufgabe zurück. Geänderte Eingaben bei Wiederverwendung dieser ID verursachen einen Konflikt.

Verwenden Sie nicht allein deshalb eine neue Anfrage-ID, weil die Verbindung eine Zeitüberschreitung hatte. Dadurch wird eine neue logische Aufgabe gestartet, statt die Aufgabe mit ungewissem Zustand wiederaufzunehmen. Stellen Sie zuerst fest, was mit der ursprünglichen Aufgabe geschehen ist; falls sie fehlgeschlagen ist, untersuchen Sie ihren Fehler, bevor Sie entscheiden, ob eine korrigierte Anfrage erforderlich ist.