Obsługa ponownych prób elementu webhook jest problemem związanym z zarządzaniem stanem. Nadawca może ponownie dostarczyć wiadomość po upływie limitu czasu, nawet jeśli odbiorca wykonał jakąś pracę. Jeśli każda próba tworzy nowy bilet lub powtarza zmianę, integracja powiększa zwykłą awarię sieci w incydent operacyjny.
Odróżnij próby doręczenia od efektów biznesowych
Zdefiniuj klucz dostawy, korzystając z udokumentowanej tożsamości dostawcy oraz zakresu subskrypcji lub dzierżawy. Oddzielnie zdefiniuj efekt biznesowy, taki jak aktualizacja jednego istniejącego wyniku uwierzytelnienia. Wiele ważnych zdarzeń może zgodnie z prawem odnosić się do tego samego ustalenia, natomiast wielokrotne dostarczenie jednego zdarzenia nie powinno powodować jego skutku dwukrotnie.
Wskazówki dotyczące webhoona GitHuba mówi, że żądane ponowne dostawy zachowują X-GitHub-Delivery. Zaleca również udzielenie odpowiedzi 2XX w ciągu dziesięciu sekund i rozważenie przetwarzania asynchronicznego. Traktuj je jako udokumentowane zachowania specyficzne dla GitHuba. Nie obiecuj, że każdy dostawca automatycznie ponawia próbę lub wykorzystuje ten sam limit czasu; potwierdzić swoją aktualną politykę dostaw i drogę odzyskiwania w przypadku nieudanej dostawy.
Potwierdzenie na prawej granicy
Najpierw zweryfikuj wydarzenie, a następnie trwale zapisz zaakceptowaną pracę przed potwierdzeniem sukcesu. Przetwarzaj kosztowną pracę z kolejki. Jeśli trwała akceptacja nie powiedzie się, nie wysyłaj odpowiedzi o powodzeniu tylko dlatego, że analiza się powiodła. I odwrotnie, nie wstrzymuj połączenia do czasu zakończenia długiego dochodzenia, gdy dostawca wymaga szybkiej odpowiedzi.
Używaj stanów takich jak w kolejce, przetwarzanie, oczekiwanie na ponowną próbę, ukończone i utracona wiadomość. Śledź liczbę prób i czas kolejnej próby. Awaria pracownika może spowodować porzucenie roszczenia związanego z przetwarzaniem, dlatego należy zdefiniować bezpieczną zasadę dzierżawy lub odzyskiwania. Chroń unikalność i zmiany stanów za pomocą ograniczeń bazy danych lub transakcji, a nie kontroli odczytu i zapisu podatnej na równoczesne dostarczanie.
Zaprojektuj efekty, które można powtórzyć
W przypadku wywołań zewnętrznych użyj obsługiwanego klucza idempotencji lub stabilnej tożsamości docelowej, jeśli jest dostępna. Kiedy przerwa w grze pozostawia wynik niepewny, przeczytaj lub uzgodnij cel przed powtórzeniem efektu ubocznego. Jeśli dalszy interfejs API nie może zapewnić idempotencji, udokumentuj szczątkowe ryzyko duplikacji i dodaj kompensującą ścieżkę przeglądu.
Załóżmy, że zweryfikowana dostawa znajduje się w kolejce, ale informacja o powodzeniu została utracona. Późniejsze żądanie ponownego dostarczenia powinno znaleźć ten sam stan dostarczenia, a nie utworzyć drugi bilet tylko dlatego, że nadeszło kolejne żądanie HTTP. Osobno załóżmy, że pracownik wywołuje interfejs API biletu i przekracza limit czasu po tym, jak interfejs API mógł utworzyć bilet. Sama deduplikacja dostarczania kolejki nie jest w stanie rozwiązać tej niepewności na dalszym etapie: sprawdź obiekt docelowy lub użyj obsługiwanego przez niego klucza idempotencji przed ponownym utworzeniem.
Są to hipotetyczne ścieżki awarii, a nie wykonywana kolejka, test zegara wirtualnego lub gwarancja dokładnie raz. Przetestuj równoczesne duplikaty, przerwę w działaniu pracownika, porzuconą dzierżawę przetwarzania i ograniczone wyczerpanie, korzystając z rzeczywistej umowy dotyczącej przechowywania i dalszego przetwarzania. Przesyłka niedostarczona powinna zachować bezpieczny dowód i wymagać kontrolowanego odtworzenia po usunięciu przyczyny, a nie cichego resetowania licznika prób.
Zamknij pętlę wyczerpanej pracy
Używaj ograniczonych ponownych prób z wycofywaniem i odpowiednimi sygnałami ograniczenia szybkości. Najlepsze praktyki GitHub REST wyjaśnić zachowanie uwzględniające limity szybkości dla tego interfejsu API; zastosować faktyczną umowę o świadczenie usług niższego szczebla do produkcji. Przenieś wielokrotnie wadliwe pozycje do kontrolowanej kolejki niedostarczonych wiadomości i powiadom operatora odpowiedzialnego, przedstawiając bezpieczne dowody i wskazując następny krok.
Oddziel możliwe do ponowienia błędy transportu od trwałych błędów schematu lub autoryzacji. Powtarzanie nieautoryzowanego żądania w nieskończoność nie naprawi jego pozwolenia. Zachowaj wystarczającą ilość dowodów tożsamości i wyniku, aby wyjaśnić końcowy stan każdego zdarzenia i zapewnij przemyślaną procedurę odtwarzania przez operatora po korekcie. Monitoruj najstarszą pracę w kolejce, wyczerpanie się liczby ponownych prób i nierozwiązane wyniki, a nie tylko liczbę udanych odpowiedzi HTTP. Nie pokazano tutaj żadnych zachowań związanych z ponownymi próbami dostawcy na żywo ani funkcji EmailAuth .