Planning réessais webhook

Les récepteurs de webhooks et les workers de livraison ont besoin d'une liste explicite de temps d'attente avant chaque réessai, pas d'une promesse vague que le backoff sera appliqué quelque part dans la pile. Ce constructeur de planning de réessais de livraison webhook prend un nombre maximal de réessais, un délai de base strictement positif et une stratégie fixe, linéaire ou exponentielle, puis renvoie les délais par tentative, les attentes cumulées et une courte formule que vous pouvez figer dans des tests ou afficher à côté d'un tableau de bord. La même logique pure s'exécute gratuitement dans le navigateur et via l'API, de sorte qu'un plan d'échelle exponentielle à cinq réessais hors ligne correspond à ce que votre worker en périphérie utilisera pour configurer des chemins de notification ou des boucles de livraison personnalisées. Les délais de base invalides échouent immédiatement avec invalid_input au lieu d'inventer des attentes nulles ou négatives qui satureraient une file.

Qu'est-ce qu'un planning de réessais webhook et en quoi les trois stratégies diffèrent

Sans planning publié, les opérateurs ne peuvent pas raisonner sur la latence de livraison au pire cas, et les tests de charge ne reproduisent pas les écarts exacts qu'un worker de production insérera entre les réessais. Le backoff fixe conserve le même délai de base à chaque tentative : simple à raisonner et clément pour les systèmes en aval qui n'ont besoin que d'un court refroidissement. Le backoff linéaire multiplie le délai de base par l'index de tentative (base un), de sorte que les réessais ultérieurs attendent proportionnellement plus longtemps sans croître aussi vite qu'une pure exponentielle. Un planning de réessais de livraison webhook est la liste ordonnée des délais que vous attendez avant la tentative un, la deux, et ainsi de suite après un POST échoué vers l'URL de l'abonné. Cette capacité encode trois familles courantes de backoff utilisées dans les bus de messages et les clients HTTP. Le backoff exponentiel double le délai précédent à chaque fois en utilisant base_delay multiplié par deux à la puissance tentative moins un, le schéma classique pour les pannes réseau transitoires et les limites de débit. Vous fournissez max_retries comme le nombre d'emplacements de réessai à matérialiser, base_delay comme graine positive dans l'unité choisie (souvent des millisecondes) et strategy parmi fixed, linear ou exponential. La réponse reprend ces entrées, liste les délais dans l'ordre, les somme en total_wait et développe un tableau schedule avec numéro de tentative, délai et attente cumulée afin que graphiques d'interface et générateurs de configuration n'aient pas besoin d'arithmétique supplémentaire.

Contrat d'entrée, forme de la réponse et cas d'échec de validation

Envoyez en POST un corps JSON avec trois champs obligatoires. max_retries est un entier de un à cent indiquant combien de réessais planifier. base_delay est un nombre fini strictement supérieur à zéro dans toute unité cohérente ; zéro et les valeurs négatives sont rejetés car une attente non positive fait soit du busy-spin, soit n'a aucun sens pour la planification. strategy doit être la chaîne fixed, linear ou exponential (insensible à la casse après trim). Des alias tels que retries, base_ms et backoff sont acceptés pour que les formes de configuration existantes se mappent proprement. Champs manquants, max_retries non entiers, base_delay non fini et stratégies inconnues lèvent invalid_input et ne sont pas facturés. En cas de succès le corps inclut max_retries, base_delay, strategy, delays comme tableau plat, total_wait comme somme des délais, attempt_count égal à max_retries, schedule comme objets avec attempt, delay et cumulative, et formula rappelant la forme fermée de la stratégie choisie. Exemple : max_retries cinq, base_delay mille, strategy exponential produit des délais de mille, deux mille, quatre mille, huit mille et seize mille avec total_wait de trente et un mille. Associez le planning à votre propre politique de jitter si vous avez besoin de dispersion aléatoire ; ce point d'accès omet volontairement le jitter et les horodatages d'horloge murale pour que les résultats restent déterministes entre navigateur et API. Le plafond de max_retries est cent afin qu'une faute de frappe n'étende pas une charge énorme ni ne fasse déborder des produits intermédiaires sur de grandes échelles exponentielles.

Où construire un planning de réessais apporte de la valeur dans les systèmes réels

Les harnais de test de charge injectent le même tableau de délais que le worker de production, éliminant le classique écart où le staging réessaie plus vite que la production et masque des bugs de limite de débit. Les plateformes de livraison qui exposent des réglages de fiabilité des webhooks peuvent appeler ce constructeur lorsqu'un opérateur choisit le maximum de réessais et un mode de backoff, puis stocker les délais résultants à côté du secret du point d'accès et de la clé de signature. Les runbooks d'incidents bénéficient d'un total_wait imprimable pour que l'astreinte sache combien de temps un abonné instable peut retarder avant la dernière tentative. Les générateurs OpenAPI et SDK peuvent documenter des échelles d'exemple concrètes sans maintenir à la main des tables qui divergent du code d'exécution. Comme l'implémentation est du parse pur de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant ; une validation échouée ne consomme pas de solde. Gardez base_delay et total_wait dans la même unité que vos primitives de sleep afin de ne jamais convertir par accident des millisecondes en secondes en branchant le planning dans une boucle de worker.