Hoe worden mislukte webhooks opnieuw geprobeerd, en komen events op volgorde aan?

Je ontvanger kan een event opslaan, ook als de verzender de bevestiging nooit ontvangt. Een nieuwe poging kan daardoor werk herhalen dat je applicatie al heeft geaccepteerd.

Nieuwe pogingen vertragen sommige events. Nieuwere events kunnen aankomen voordat die pogingen zijn afgerond. Sla event-ID's en tijdstippen van optreden op, zodat die afleveringen nieuwer werk niet kunnen overschrijven.

Wat telt als een mislukte aflevering?

Bird beschouwt een aflevering als mislukt wanneer het een niet-succesvolle respons ontvangt of het verzoek een time-out krijgt.

Retourneer HTTP 2xx nadat je het event hebt opgeslagen, om nieuwe pogingen voor die aflevering te stoppen. Een redirect, clientfout of serverfout blijft beschikbaar voor een nieuwe poging.

400 registreert bijvoorbeeld een afgewezen verzoek, maar vertelt Bird niet om het te verwijderen. Gebruik een foutrespons wanneer handtekeningverificatie of duurzame opslag mislukt, zodat de aflevering kan worden hersteld.

Sla het event op voordat je het bevestigt. Eerst succes retourneren kan het event verliezen als de latere opslagactie mislukt.

Houd zware verwerking in een achtergrondworker zodat je ontvanger snel kan reageren. De taak van de ontvanger is het event te verifiëren en op te slaan voordat die verwerking begint.

Wat is het schema voor nieuwe pogingen?

Bird gebruikt zeven vertragingen voor nieuwe pogingen na de eerste poging, voor in totaal acht pogingen.

Het schema geeft je ongeveer 27,5 uur om een ontvanger te repareren voordat de automatische pogingen stoppen.

Bird past elke wachttijd willekeurig aan met maximaal 20 procent in beide richtingen, om nieuwe pogingen te spreiden na een storing. Een vertraging van vijf minuten varieert daarom van vier tot zes minuten vóór andere aanpassingen.

Een throttlingrespons of time-out kan de volgende wachttijd wijzigen. Bird houdt ook rekening met Retry-After, een responsheader die een vertraging aanvraagt vóór de volgende poging. Beschouw het schema als een herstelvenster in plaats van een exacte deadline.

Elke nieuwe poging behoudt de webhook-id van het event, zodat je ontvanger duplicaten kan herkennen.

Wat gebeurt er na de laatste poging?

Automatische retries stoppen voor die aflevering. Je kunt replay aanvragen voor de mislukte afleveringen.

Je vraagt heraflevering aan met createWebhookReplay, of via de dashboardpagina van het endpoint. Replay leest het afleveringspogingen-log en selecteert de events die daar zijn mislukt. Een event dat Bird nooit is geprobeerd, bijvoorbeeld omdat het binnenkwam terwijl het endpoint gepauzeerd was, heeft geen poging om te selecteren, dus replay kan het niet herstellen.

De respons is 202, wat betekent dat replay in de wachtrij staat voor achtergronduitvoering. Er wordt geen aantal of taak-ID meegestuurd. Gebruik listWebhookAttempts om volgende pogingen te bekijken.

Elke herlevering doet één poging in plaats van het bovenstaande schema. Bird registreert de poging en sluit de taak af, ongeacht of je ontvanger het geaccepteerd heeft. Herleveren naar een ontvanger die nog steeds niet werkt kost daarom één verzoek per event in plaats van acht. Repareer de ontvanger en speel daarna opnieuw af. Die mislukkingen laten de status van het endpoint ongemoeid. Een geaccepteerde herlevering heft degradatie op.

Replay slaat afleveringen over die al succesvol zijn bevestigd. Een heraflevering behoudt zijn oorspronkelijke webhook-id, dus je duplicaatafhandeling blijft van toepassing.

Stel since en until in als datum-tijdstrings om het herstelvenster af te bakenen. Beide grenzen zijn inclusief. Beide worden vergeleken met het tijdstip van de afleverpoging, niet met het tijdstip waarop het event plaatsvond. Als je since weglaat, begint het venster 24 uur vóór het verzoek, dus een oudere storing heeft een expliciet starttijdstip nodig. Als je until weglaat, eindigt het venster op het tijdstip van het verzoek.

Pogingen worden drie dagen bewaard, en zo ver terug reikt replay. Een eerdere since verbreedt het venster zonder iets ouders te herstellen. Eén replay dekt bovendien maximaal de oudste 10.000 events in het venster, dus een lange storing vereist meerdere smallere vensters.

Een organisatie kan 20 replays per UTC-dag aanvragen. Een volgend verzoek ontvangt 429 met WebhookReplayQuotaExceeded, dus combineer herstel in één venster in plaats van replay per event aan te vragen.

Wat als mijn endpoint blijft falen?

Bird markeert een falend endpoint als gedegradeerd. Na ongeveer vijf dagen ononderbroken fouten wordt de aflevering gepauzeerd.

Je kunt de status lezen als active, degraded of paused. Een gedegradeerd endpoint blijft afleveringen en retries ontvangen. Een succesvolle aflevering heft de degradatie op en reset de teller voor opeenvolgende fouten.

Een gepauzeerd endpoint ontvangt geen events meer en hervat niet automatisch. Schakel het opnieuw in met updateWebhook door status in te stellen op active. Replay daarna het venster om de afleveringen te herstellen die vóór de pauze zijn mislukt. Schakel eerst opnieuw in: een replay die wordt aangevraagd terwijl het endpoint nog gepauzeerd is, retourneert 202 en levert niets opnieuw af. De schrijfbare statuswaarden zijn active en paused.

Het wijzigen van de ontvangende url of het voltooien van een succesvolle testaflevering heft ook de degradatie op. De vervangende URL moet publiek bereikbaar zijn HTTPS, dus privéadressen kunnen de bereikbaarheid niet herstellen. URL's langer dan 2048 tekens slagen niet voor validatie, dus verkort een gegenereerde URL voordat je hem indient.

Het bewerken van de beschrijving of eventabonnementen van het endpoint toont niet aan dat het requests kan ontvangen. Die wijzigingen laten de degradatie intact, net als een mislukte testaflevering.

Bird mailt de eigenaren van de organisatie wanneer een endpoint gedegradeerd raakt. Er wordt geen nieuwe degradatie-e-mail gestuurd totdat het endpoint herstelt. Herhaalde fouten produceren dus niet bij elke poging een e-mail. Een fout na herstel start een nieuwe periode van degradatie.

Is er een dead-letter queue?

Bird biedt geen aparte wachtrij van mislukte events om uit te lezen. Inspecteer afleveringspogingen en vraag in plaats daarvan replay aan.

Repareer de receiver, schakel het endpoint zo nodig opnieuw in en replay het getroffen venster. Er is geen aparte wachtrij om daarna te legen.

Komen events op volgorde aan?

Events kunnen in een andere volgorde aankomen dan de volgorde waarin ze plaatsvonden.

Een email.delivered-event kan aankomen vóór het email.accepted-event van hetzelfde bericht. Vergelijk eventtijden in timestamp voordat je een wijziging toepast die nieuwere status zou overschrijven.

Volg elk onderdeel van een SMS-charge apart. De afleveringskosten en een carrier fee zijn bijvoorbeeld afzonderlijke kostencomponenten.

Het cost-object is null totdat een component is geprijsd. De componentwaarden zijn decimale strings of null. Het amount-veld is een decimale string met de som van de componenten in die payload.

Merge elk component op basis van het nieuwste eventtijdstempel. Het hele object vervangen kan een component wissen die door een ander event is aangeleverd, of een oudere charge herstellen.

Een null-component betekent dat het niet is geprijsd in die payload. Het betekent geen charge van nul. SMS-events beschrijft die merge in context, en webhooks behandelt afleveringssemantiek.