Skip to main content
Les exemples Node utilisent le client Node commun (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 budget reads sans accélérer le run.
  • Envoyez If-None-Match avec l’ETag précédent : le 304 n’a pas de corps. Il compte quand même dans le budget reads.

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’un Promise.all sur 100 éléments. Pour POST /v1/go/run (synchrone), limitez-vous à 3 appels en parallèle par clé.

Reprise après crash

Stockez run.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.