retriever.mjs).
Problème : timeouts réseau, 429, redémarrages. Vous voulez zéro doublon et zéro run perdu.
Idempotence de la création
Générez l’Idempotency-Key avant l’appel et stockez-la avec votre job. Si l’appel échoue sans réponse, rejouez-le avec la même clé : vous récupérez le même run.
409 idempotency_conflict signifie qu’une clé a été réutilisée avec un autre corps. C’est un bug du client : ne réessayez pas.
POST /v1/workspaces, POST /v1/workspaces/{id}/tables, POST /v1/go/* et POST /services/{name} n’ont pas d’idempotence. Ne les rejouez pas automatiquement après un 5xx ou un timeout : vérifiez d’abord si la ressource existe.
Réessayer seulement ce qui peut l’être
Le client
call() applique ces règles, sauf conversation_busy, que vous gérez selon votre logique métier.
Polling économe
- Respectez
Retry-After(15 s pour un run actif). Poller plus vite consomme votre budgetreadssans accélérer le run. - Envoyez
If-None-Matchavec l’ETagprécédent : le304n’a pas de corps. Il compte quand même dans le budgetreads.
Parallélisme
Par défaut, une clé peut créer 30 runs par minute. La limite « 3 simultanées » porte sur les requêtes HTTP en cours, pas sur les runs actifs. Pour un gros batch, étalez les créations (par exemple une toutes les 2 s) plutôt qu’unPromise.all sur 100 éléments. Pour POST /v1/go/run (synchrone), limitez-vous à 3 appels en parallèle par clé.
Reprise après crash
Stockezrun.id dès la réponse 202. Au redémarrage, reprenez le polling des runs non terminés au lieu d’en créer de nouveaux. Un run en recovering reprend tout seul côté Retriever.