Webhook-Wiederholungsplan

Webhook-Empfänger und Zustell-Worker brauchen eine explizite Liste von Wartezeiten vor jedem erneuten Versuch, kein vages Versprechen, dass Backoff irgendwo im Stack greift. Dieser Generator für Webhook-Zustellungs-Wiederholungspläne nimmt eine maximale Wiederholungsanzahl, eine streng positive Basisverzögerung und eine Strategie fest, linear oder exponentiell und liefert die Verzögerungen je Versuch, kumulierte Wartezeiten sowie eine kurze Formel, die Sie in Tests verankern oder neben einem Dashboard anzeigen können. Dieselbe reine Logik läuft kostenlos im Browser und über die API, sodass die Offline-Planung einer fünfstufigen exponentiellen Leiter dem entspricht, was Ihr Edge-Worker bei Notify-Pfaden oder eigenen Zustellschleifen nutzt. Ungültige Basisverzögerungen scheitern sofort mit invalid_input, statt Null- oder Negativwartezeiten zu erfinden, die eine Warteschlange im Busy-Loop halten würden.

Was ein Webhook-Wiederholungsplan ist und wie sich die drei Strategien unterscheiden

Ohne veröffentlichten Plan können Betreiber die Worst-Case-Zustelllatenz nicht einschätzen, und Lasttests können die exakten Lücken nicht reproduzieren, die ein Produktions-Worker zwischen Wiederholungen einfügt. Fester Backoff behält bei jedem Versuch dieselbe Basisverzögerung: einfach zu durchschauen und schonend für nachgelagerte Systeme, die nur eine kurze Abkühlphase brauchen. Linearer Backoff multipliziert die Basisverzögerung mit dem einsbasierten Versuchsindex, sodass spätere Wiederholungen proportional länger warten, ohne so schnell zu explodieren wie reines exponentielles Wachstum. Ein Webhook-Zustellungs-Wiederholungsplan ist die geordnete Liste der Verzögerungen, die Sie vor Versuch eins, Versuch zwei und so weiter nach einem fehlgeschlagenen POST an die Abonnenten-URL abwarten. Diese Fähigkeit kodiert drei gängige Backoff-Familien aus Message-Bussen und HTTP-Clients. Exponentieller Backoff verdoppelt die vorherige Verzögerung jeweils mit base_delay mal zwei hoch Versuch minus eins — das klassische Muster bei transienten Netzfehlern und Ratenlimits. Sie liefern max_retries als Anzahl zu materialisierender Wiederholungsplätze, base_delay als positiven Keim in Ihrer gewählten Einheit (meist Millisekunden) und strategy als fixed, linear oder exponential. Die Antwort spiegelt diese Eingaben, listet delays geordnet, summiert sie als total_wait und expandiert ein schedule-Array mit Versuchsnummer, Verzögerung und kumulativer Wartezeit, sodass UI-Diagramme und Konfigurationsgeneratoren keine Extra-Arithmetik brauchen.

Eingabevertrag, Antwortform und wann die Validierung scheitert

Senden Sie per POST einen JSON-Körper mit drei Pflichtfeldern. max_retries ist eine ganze Zahl von eins bis hundert und benennt, wie viele Wiederholungsversuche geplant werden. base_delay ist eine endliche Zahl strikt größer als null in einer konsistenten Einheit; null und negative Werte werden abgelehnt, weil eine nicht positive Wartezeit entweder busy-spinnt oder für die Planung sinnlos ist. strategy muss die Zeichenkette fixed, linear oder exponential sein (nach Trim ohne Groß-/Kleinschreibung). Alias-Schlüssel wie retries, base_ms und backoff werden akzeptiert, damit bestehende Konfigurationsformen sauber abbilden. Fehlende Felder, nicht-ganzzahlige max_retries, nicht-endliche base_delay und unbekannte Strategien lösen invalid_input aus und werden nicht abgerechnet. Bei Erfolg enthält der Körper max_retries, base_delay, strategy, delays als flaches Array, total_wait als Summe der Verzögerungen, attempt_count gleich max_retries, schedule als Objekte mit attempt, delay und cumulative sowie formula mit der geschlossenen Form der gewählten Strategie. Beispiel: max_retries fünf, base_delay eintausend, strategy exponential liefert Verzögerungen eintausend, zweitausend, viertausend, achttausend und sechzehntausend mit total_wait einunddreißigtausend. Kombinieren Sie den Plan mit Ihrer eigenen Jitter-Politik, wenn Sie zufällige Streuung brauchen; dieser Endpunkt lässt Jitter und Wanduhr-Zeitstempel absichtlich weg, damit Ergebnisse zwischen Browser und API deterministisch bleiben. max_retries ist auf hundert begrenzt, damit ein Tippfehler kein riesiges Payload aufbläht und Zwischenprodukte bei großen exponentiellen Leitern nicht überlaufen.

Wo das Erstellen eines Wiederholungsplans in realen Systemen Nutzen stiftet

Lasttest-Harnesses injizieren dasselbe Verzögerungsarray wie der Produktions-Worker und schließen die klassische Lücke, in der Staging schneller erneut versucht als Produktion und Ratenlimit-Fehler maskiert. Zustellplattformen mit Webhook-Zuverlässigkeitseinstellungen können diesen Generator aufrufen, wenn ein Operator Maximalversuche und einen Backoff-Modus wählt, und die resultierenden Verzögerungen neben Endpoint-Geheimnis und Signaturschlüssel speichern. Incident-Runbooks profitieren von einem druckbaren total_wait, damit Bereitschaftspersonal weiß, wie lange ein unzuverlässiger Abonnent vor dem letzten Versuch nachhängen kann. OpenAPI- und SDK-Generatoren können konkrete Beispielleitern dokumentieren, ohne Tabellen von Hand zu pflegen, die vom Laufzeitcode abdriften. Weil die Implementierung reines Parse-Tier-A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Grundpreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz; fehlgeschlagene Validierung wird nicht berechnet. Halten Sie base_delay und total_wait in derselben Einheit wie Ihre Sleep-Primitive, damit Sie beim Einbinden des Plans in eine Worker-Schleife nie versehentlich Millisekunden in Sekunden umrechnen.