Gérer les erreurs du SDK Go et récupérer les tâches interrompues

Utilisez Go 1.22 ou une version ultérieure avec le module officiel solvethree.com/sdk, en version v0.1.0. Consultez les instructions d’intégration Go pour la configuration.

Définissez les variables d’environnement côté serveur SOLVETHREE_API_KEY et SOLVETHREE_PROXY. Remplacez Site et Action dans l’exemple par le nom d’hôte et l’action de votre cible. Le site doit disposer d’un profil actif dans votre espace de travail ; l’envoi de son nom d’hôte n’en crée pas. Cette requête reCAPTCHA utilise un seul proxy et n’a pas besoin de Type ni de 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.
}

L’exemple définit un délai de contexte de 180 secondes et journalise les ID de reprise lorsqu’une erreur du SDK les expose. La journalisation ne garantit pas une reprise durable : enregistrez l’input d’origine, le RequestID renvoyé et tout TaskID avant de supprimer l’erreur.

« Tâche prête » signifie qu’une solution est disponible, pas que la cible l’a acceptée. Le SDK ne la soumet pas à votre place. Soumettez Solution.Token en utilisant l’identité de navigateur renvoyée et, pour cet exemple à proxy unique, le proxy d’origine.

Examinez les erreurs encapsulées avec errors.As et l’annulation avec errors.Is. Ces vérifications répondent à des questions différentes : une même erreur peut contenir des ID de reprise, encapsuler une erreur HTTP et devoir malgré tout être traitée comme une opération interrompue.

L’exemple recherche une erreur APIError imbriquée dans sa branche de reprise. Vérifiez séparément l’annulation avec errors.Is si votre application doit distinguer un dépassement de délai d’une annulation explicite.

Solve crée la tâche une seule fois. Il retente uniquement les interrogations qui reçoivent des réponses temporaires HTTP 429, 502, 503 ou 504, en respectant Retry-After dans la limite du délai du contexte. CreateTask ne retente jamais automatiquement sa requête POST.

1. 1.

   Conserver la requête d’origine intacte

   Enregistrez toutes les données de la tâche, y compris le proxy ou la liste de candidats, avec l’ID de requête. CreateTask génère un ID de requête si vous l’omettez ; récupérez la valeur générée exposée par l’erreur de reprise. Ne reconstituez pas la requête ultérieurement à partir d’une configuration qui peut avoir changé.

2. 2.

   Utiliser GetTask lorsque l’ID de tâche est connu

   Créez un nouveau contexte si l’ancien a expiré ou a été annulé, puis récupérez le TaskID enregistré avec GetTask. Continuez à attendre pour pending ou solving, utilisez la solution uniquement pour ready et arrêtez-vous pour failed.

3. 3.

   Relancer la création uniquement si l’ID de tâche est inconnu

   Définissez RequestID sur le TaskRequest d’origine enregistré avec l’ID de requête récupéré, puis appelez CreateTask avec ces mêmes données. Réutiliser le même ID et la même requête renvoie la tâche existante. Modifier les données tout en réutilisant cet ID provoque un conflit.

N’utilisez pas un nouvel ID de requête simplement parce que la connexion a dépassé le délai. Cela démarre une nouvelle tâche logique au lieu de reprendre celle dont l’état est incertain. Déterminez d’abord ce qui est arrivé à la tâche d’origine ; si elle a échoué, examinez son erreur avant de décider si une requête corrigée est nécessaire.