Twój odbiornik może zapisać zdarzenie, nawet jeśli nadawca nigdy nie otrzyma jego potwierdzenia. Ponowienie może więc powtórzyć pracę, którą Twoja aplikacja już przyjęła.
Ponowienia opóźniają niektóre zdarzenia. Nowsze zdarzenia mogą dotrzeć, zanim ponowienia się zakończą. Zapisuj identyfikatory zdarzeń i czasy wystąpienia, aby te dostarczenia nie nadpisywały nowszych danych.
Co uznawane jest za nieudane dostarczenie?
Bird uznaje dostarczenie za nieudane, gdy otrzyma odpowiedź inną niż sukces lub gdy żądanie przekroczy limit czasu.
Zwróć HTTP 2xx po zapisaniu zdarzenia, aby zatrzymać ponowienia dla tego dostarczenia. Przekierowanie, błąd klienta lub błąd serwera pozostaje kwalifikowane do ponowienia.
Na przykład 400 rejestruje odrzucone żądanie, ale nie informuje Bird o konieczności jego odrzucenia. Użyj odpowiedzi z błędem, gdy weryfikacja podpisu lub trwały zapis się nie powiedzie, aby dostarczenie mogło zostać odzyskane.
Zapisz zdarzenie przed potwierdzeniem odbioru. Zwrócenie sukcesu w pierwszej kolejności może spowodować utratę zdarzenia, jeśli późniejsza operacja zapisu się nie powiedzie.
Przenieś wolne przetwarzanie do workera w tle, aby odbiornik mógł odpowiedzieć szybko. Zadaniem odbiornika jest zweryfikowanie i utrwalenie zdarzenia, zanim rozpocznie się jego przetwarzanie.
Jaki jest harmonogram ponowień?
Bird stosuje siedem opóźnień ponowień po pierwszej próbie, co daje łącznie osiem prób.
| Ponowienie | Opóźnienie od poprzedniej próby | Przybliżony czas od początku przed korektami czasowymi |
|---|---|---|
| 1 | 5 sekund | 5 sekund |
| 2 | 5 minut | 5 minut 5 sekund |
| 3 | 30 minut | 35 minut 5 sekund |
| 4 | 2 godziny | 2 godziny 35 minut 5 sekund |
| 5 | 5 godzin | 7 godzin 35 minut 5 sekund |
| 6 | 10 godzin | 17 godzin 35 minut 5 sekund |
| 7 | 10 godzin | 27 godzin 35 minut 5 sekund |
Harmonogram daje Ci około 27,5 godziny na naprawę odbiornika, zanim automatyczne próby się wyczerpią.
Bird losowo koryguje każdy odstęp o maksymalnie 20 procent w górę lub w dół, aby rozproszyć ponowienia po awarii. Pięciominutowy odstęp waha się więc od czterech do sześciu minut przed innymi korektami.
Odpowiedź ograniczająca częstotliwość lub przekroczenie limitu czasu może zmienić następny odstęp. Bird uwzględnia też Retry-After, nagłówek odpowiedzi żądający opóźnienia przed kolejną próbą. Traktuj harmonogram jako okno naprawcze, a nie dokładny termin.
Każde ponowienie zachowuje webhook-id zdarzenia, dzięki czemu odbiornik może rozpoznawać duplikaty.
Co dzieje się po ostatnim ponowieniu?
Automatyczne ponawianie dla tego dostarczenia zostaje zakończone. Możesz zażądać powtórki dostarczeń, które się nie powiodły.
Powtórkę żądasz za pomocą createWebhookReplay lub przez stronę dashboardu endpointu. Powtórka odczytuje log prób dostarczenia i wybiera zdarzenia, które tam się nie powiodły. Zdarzenie Bird, które nigdy nie zostało podjęte, na przykład takie, które nadeszło, gdy endpoint był wstrzymany, nie ma próby do wybrania, więc powtórka nie może go odzyskać.
Odpowiedź to 202, co oznacza, że odtwarzanie jest umieszczone w kolejce do wykonania w tle. Nie zawiera liczby zdarzeń ani identyfikatora zadania. Użyj listWebhookAttempts, aby sprawdzić kolejne próby.
Każde ponowne dostarczenie to jedna próba, a nie cały harmonogram powyżej. Bird rejestruje próbę i kończy zadanie niezależnie od tego, czy odbiornik je zaakceptował. Ponowne dostarczanie do odbiornika, który wciąż nie działa, kosztuje więc jedno żądanie na zdarzenie zamiast ośmiu. Napraw odbiornik, a potem ponów dostarczanie. Te niepowodzenia nie wpływają na kondycję endpointu. Zaakceptowane ponowne dostarczenie usuwa degradację.
Powtórka pomija dostarczenia już pomyślnie potwierdzone. Ponowne dostarczenie zachowuje oryginalny webhook-id, więc Twoja obsługa duplikatów nadal działa.
Ustaw since i until jako ciągi daty i czasu, aby ograniczyć okno odzyskiwania. Obie granice są włącznie. Obie odnoszą się do czasu próby dostarczenia, nie do czasu wystąpienia zdarzenia. Pominięcie since rozpoczyna okno 24 godziny przed żądaniem, więc starsze awarie wymagają jawnego czasu rozpoczęcia. Pominięcie until kończy okno w momencie wysłania żądania.
Próby są przechowywane przez trzy dni, co wyznacza maksymalny zasięg ponownego dostarczania. Wcześniejsza wartość since poszerza okno, ale nie odzyskuje starszych zdarzeń. Jedno ponowne dostarczanie obejmuje co najwyżej 10 000 najstarszych zdarzeń w oknie, więc długa awaria wymaga kilku węższych okien.
Organizacja może zażądać 20 powtórek na dobę UTC. Kolejne żądanie otrzymuje 429 z WebhookReplayQuotaExceeded, więc łącz odzyskiwanie w jedno okno zamiast żądać powtórki dla każdego zdarzenia.
Co się stanie, jeśli mój endpoint wciąż nie odpowiada?
Bird oznacza niesprawny endpoint jako zdegradowany. Wstrzymuje dostarczanie po około pięciu dniach nieprzerwanego niepowodzenia.
Możesz odczytać jego status jako active, degraded lub paused. Zdegradowany endpoint nadal otrzymuje dostarczenia i ponawiania. Pomyślne dostarczenie usuwa degradację i resetuje licznik ciągłych niepowodzeń.
Wstrzymany endpoint przestaje otrzymywać zdarzenia i nie wznawia się automatycznie. Włącz go ponownie za pomocą updateWebhook, ustawiając status na active. Następnie odtwórz okno, aby odzyskać dostarczenia, które nie powiodły się przed wstrzymaniem. Najpierw włącz endpoint: powtórka zażądana, gdy endpoint jest nadal wstrzymany, zwraca 202 i nie dostarcza ponownie niczego. Dostępne do zapisu wartości statusu to active i paused.
Zmiana odbierającego url lub pomyślne dostarczenie testowe również usuwają degradację. Zastępczy URL musi być publicznie osiągalny HTTPS, więc adresy prywatne nie naprawią osiągalności. URL-e dłuższe niż 2048 znaków nie przechodzą walidacji, więc skróć wygenerowany URL przed wysłaniem.
Edycja opisu endpointu lub subskrypcji zdarzeń nie dowodzi, że endpoint może odbierać żądania. Te zmiany nie usuwają degradacji, podobnie jak nieudane dostarczenie testowe.
Bird wysyła e-mail do właścicieli organizacji, gdy endpoint staje się zdegradowany. Kolejny e-mail o degradacji nie jest wysyłany, dopóki endpoint nie odzyska sprawności. Powtarzające się niepowodzenia nie generują więc e-maila przy każdej próbie. Niepowodzenie po odzyskaniu sprawności rozpoczyna kolejny okres degradacji.
Czy istnieje kolejka niedostarczonych zdarzeń?
Bird nie udostępnia osobnej kolejki nieudanych zdarzeń do odczytu. Zamiast tego sprawdź próby dostarczenia i zażądaj powtórki.
| Zadanie odzyskiwania | Mechanizm |
|---|---|
| Sprawdzanie niepowodzeń | Próby dostarczenia rejestrują wynik i opóźnienie każdego żądania HTTP, od najnowszych. |
| Zatrzymanie powtarzanego dostarczania do uszkodzonego odbiornika | Wstrzymanie wyłącza endpoint z dostarczania. |
| Odzyskiwanie nieudanych dostarczeń | Powtórka żąda ponownego dostarczenia w oknie czasowym. |
Napraw odbiornik, w razie potrzeby włącz go ponownie i odtwórz odpowiednie okno. Nie ma osobnej kolejki do opróżnienia po tym.
Czy zdarzenia przychodzą w kolejności?
Zdarzenia mogą przychodzić w innej kolejności niż ta, w której wystąpiły.
Zdarzenie email.delivered może dotrzeć przed zdarzeniem email.accepted tej samej wiadomości. Porównaj czasy zdarzeń w timestamp, zanim zastosujesz zmianę, która nadpisałaby nowszy stan.
Śledź każdą część opłaty SMS oddzielnie. Na przykład opłata za dostarczenie i opłata operatora to osobne składniki kosztu.
Obiekt cost ma wartość null, dopóki składnik nie zostanie wyceniony. Wartości składników to ciągi dziesiętne lub null. Pole amount to ciąg dziesiętny będący sumą składników obecnych w tym payloadzie.
Scalaj każdy składnik, używając najnowszego znacznika czasu zdarzenia. Zastąpienie całego obiektu może usunąć składnik dostarczony przez inne zdarzenie lub przywrócić starszą opłatę.
Składnik o wartości null oznacza, że nie został wyceniony w tym payloadzie. Nie oznacza opłaty równej zero. Zdarzenia SMS opisują to scalanie w kontekście, a webhooki omawiają semantykę dostarczania.
W skrócie
Ponowienia działają według stałego harmonogramu.
Osiem prób rozłożonych jest na około 27,5 godziny przed korektami czasowymi. Losowe zmiany odstępów rozpraszają ponowienia, dzięki czemu odbiorcy nie otrzymują zsynchronizowanej fali żądań.
Potwierdzaj odbiór po trwałym zapisie.
Odpowiedź 2xx zatrzymuje ponowienia i wyklucza to dostarczenie z odtwarzania pominiętych zdarzeń. Odpowiedź z błędem pozostawia je do ponowienia.
Wstrzymany endpoint wymaga ręcznego przywrócenia.
Włącz go ponownie, a następnie odtwórz dostarczenia, które nie powiodły się przed wstrzymaniem. Zdarzenia, które nadeszły, gdy endpoint był wstrzymany, nigdy nie zostały podjęte, więc powtórka nie może ich odzyskać.
Używaj czasu zdarzenia do stosowania aktualizacji.
Dostarczanie jest nieuporządkowane. Porównuj znaczniki czasu wystąpienia i scalaj częściowe koszty SMS według komponentów.