Piano riprova webhook

I ricevitori di webhook e i worker di consegna necessitano di un elenco esplicito di tempi di attesa prima di ogni riprova, non di una vaga promessa che il backoff verrà applicato da qualche parte nello stack. Questo costruttore di piani di riprova per la consegna webhook accetta un numero massimo di riprove, un ritardo base strettamente positivo e una strategia fissa, lineare o esponenziale, e restituisce i ritardi per tentativo, le attese cumulative e una breve formula che Lei può fissare nei test o mostrare accanto a un pannello. La stessa logica pura gira gratis nel browser e tramite API, così pianificare una scala esponenziale a cinque riprove offline coincide con ciò che userà il Suo worker all'edge nel configurare percorsi di notifica o loop di consegna personalizzati. Ritardi base non validi falliscono subito con invalid_input invece di inventare attese nulle o negative che saturerebbero una coda.

Cos'è un piano di riprova webhook e come differiscono le tre strategie

Senza un piano pubblicato, gli operatori non possono ragionare sulla latenza di consegna nel caso peggiore e i test di carico non riproducono gli intervalli esatti che un worker di produzione inserirà tra le riprove. Il backoff fisso mantiene lo stesso ritardo base a ogni tentativo: semplice da ragionare e gentile con i sistemi a valle che necessitano solo di un breve raffreddamento. Il backoff lineare moltiplica il ritardo base per l'indice del tentativo (base uno), così le riprove successive attendono proporzionalmente di più senza crescere tanto in fretta quanto la pura esponenziale. Un piano di riprova per la consegna webhook è l'elenco ordinato dei ritardi che Lei attende prima del tentativo uno, del due e così via dopo un POST fallito all'URL del sottoscrittore. Questa capacità codifica tre famiglie comuni di backoff usate su bus di messaggi e client HTTP. Il backoff esponenziale raddoppia il ritardo precedente ogni volta usando base_delay per due elevato a tentativo meno uno, lo schema classico per guasti di rete transitori e limiti di frequenza. Lei fornisce max_retries come quante fessure di riprova materializzare, base_delay come seme positivo nell'unità scelta (di solito millisecondi) e strategy tra fixed, linear o exponential. La risposta ripete tali ingressi, elenca i ritardi in ordine, li somma come total_wait e espande un array schedule con numero di tentativo, ritardo e attesa cumulativa affinché grafici UI e generatori di configurazione non necessitino di aritmetica extra.

Contratto di ingresso, forma della risposta e quando fallisce la validazione

Invii in POST un corpo JSON con tre campi obbligatori. max_retries è un intero da uno a cento che indica quante riprove pianificare. base_delay è un numero finito strettamente maggiore di zero in qualsiasi unità coerente; zero e valori negativi vengono rifiutati perché un'attesa non positiva o fa busy-spin o è priva di senso per la pianificazione. strategy deve essere la stringa fixed, linear o exponential (senza distinzione di maiuscole dopo il trim). Sono accettati alias come retries, base_ms e backoff affinché forme di configurazione esistenti si mappino in modo pulito. Campi mancanti, max_retries non interi, base_delay non finito e strategie sconosciute sollevano invalid_input e non vengono fatturati. In caso di successo il corpo include max_retries, base_delay, strategy, delays come array piatto, total_wait come somma dei ritardi, attempt_count uguale a max_retries, schedule come oggetti con attempt, delay e cumulative, e formula che riformula la forma chiusa della strategia scelta. Esempio: max_retries cinque, base_delay mille, strategy exponential produce ritardi di mille, duemila, quattromila, ottomila e sedicimila con total_wait di trentuno mila. Abbini il piano alla Sua politica di jitter se le serve dispersione casuale; questo endpoint omette di proposito jitter e timestamp di orologio di parete affinché i risultati restino deterministici tra browser e API. Il tetto di max_retries è cento così un refuso non espande un payload enorme né fa overflow di prodotti intermedi su scale esponenziali ampie.

Dove costruire un piano di riprova genera valore nei sistemi reali

Gli harness di test di carico iniettano lo stesso array di ritardi usato dal worker di produzione, eliminando il classico scarto in cui lo staging riprova più in fretta della produzione e maschera bug di limite di frequenza. Le piattaforme di consegna che espongono impostazioni di affidabilità dei webhook possono chiamare questo costruttore quando un operatore sceglie il massimo di riprove e una modalità di backoff, poi memorizzare i ritardi risultanti accanto al segreto dell'endpoint e alla chiave di firma. I runbook di incidente beneficiano di un total_wait stampabile così il personale di reperibilità sa quanto un sottoscrittore instabile può ritardare prima dell'ultimo tentativo. I generatori OpenAPI e SDK possono documentare scale di esempio concrete senza mantenere a mano tabelle che divergono dal codice runtime. Poiché l'implementazione è parse puro di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello né rete in uscita; la validazione fallita non consuma saldo. Mantenga base_delay e total_wait nella stessa unità delle Sue primitive di sleep per non convertire per errore millisecondi in secondi collegando il piano a un loop di worker.