webhook wywoływany wielokrotnie przez ten sam trigger

Webhook wywoływany wielokrotnie przez ten sam trigger wymaga zabezpieczenia przed powielonym przetworzeniem zdarzenia.

Dlaczego jeden trigger może uruchomić webhook ponownie

Webhook wywoływany wielokrotnie przez ten sam trigger oznacza, że system odbiorcy otrzymał więcej niż jedno żądanie HTTP dotyczące tego samego zdarzenia albo kilku dostaw tego samego komunikatu. Nie musi to oznaczać, że trigger wykonał się błędnie. Wiele systemów webhookowych stosuje dostarczanie typu at least once, czyli dostarczenie co najmniej raz. Jeżeli nadawca nie otrzyma poprawnej odpowiedzi, połączenie zostanie przerwane albo odpowiedź nadejdzie po przekroczeniu limitu czasu, może ponowić wysyłkę. Odbiorca nie powinien więc zakładać, że każde żądanie jest nowe.

Powtórzenie może wystąpić także wtedy, gdy właściwe przetwarzanie zdarzenia zakończyło się powodzeniem, lecz odpowiedź HTTP nie dotarła do nadawcy. Z jego punktu widzenia dostawa nie została potwierdzona, dlatego uruchamia ponowną próbę. Podobny efekt może powstać po ponownym uruchomieniu procesu, zmianie konfiguracji integracji, ręcznym powtórzeniu zadania lub chwilowej niedostępności usługi odbiorczej. Sam fakt wielokrotnego wywołania nie pozwala jeszcze rozstrzygnąć, czy problem występuje po stronie triggera, transportu, mechanizmu retry, czy logiki aplikacji odbierającej.

Identyfikator zdarzenia i rozpoznawanie duplikatów

Podstawowym zabezpieczeniem jest nadanie każdemu zdarzeniu stabilnego identyfikatora, który pozostaje taki sam przy kolejnych próbach dostarczenia. Może to być identyfikator zdarzenia przekazany w treści JSON albo w nagłówku HTTP, o ile dokumentacja konkretnego nadawcy gwarantuje jego unikalność i niezmienność. Nie należy bez dodatkowych założeń traktować jako identyfikatora całego tekstu payloadu, znacznika czasu odebrania ani adresu IP nadawcy. Dwa różne zdarzenia mogą mieć taką samą treść, a ta sama dostawa może zostać zapisana w logu z różnym czasem.

Odbiorca powinien przechowywać identyfikator obsłużonego zdarzenia w trwałym magazynie danych i wymuszać jego unikalność. Gdy przychodzi kolejne żądanie z tym samym identyfikatorem, aplikacja może rozpoznać je jako duplikat i nie wykonywać ponownie operacji powodującej skutek uboczny. Przykładem takiego skutku jest utworzenie zamówienia, wysłanie wiadomości, naliczenie opłaty, zmiana statusu albo zapis pliku. Samo sprawdzenie w pamięci procesu jest niewystarczające, ponieważ po restarcie aplikacji informacja o poprzednim wywołaniu może zostać utracona, a przy wielu procesach każdy z nich może mieć osobny stan pamięci.

Idempotentne przetwarzanie przed odpowiedzią HTTP

Istotna jest kolejność operacji. Jeżeli dwa równoległe żądania sprawdzą brak identyfikatora, a dopiero potem oba wykonają działanie biznesowe, powstaje wyścig. Dlatego zapis identyfikatora i wykonanie operacji powinny być objęte mechanizmem zapewniającym atomowość albo kontrolę współbieżności właściwą dla użytej technologii. Trwały magazyn musi odrzucić drugi zapis tego samego klucza, a aplikacja powinna potraktować taki wynik jako informację, że zdarzenie jest już przetwarzane lub zostało przetworzone.

Bezpieczna obsługa często rozdziela szybkie przyjęcie żądania od dłuższej pracy. Odbiorca weryfikuje autentyczność i poprawność komunikatu, zapisuje zdarzenie wraz ze stanem przetwarzania, a następnie zwraca odpowiedź HTTP. Dalsza operacja może zostać wykonana przez osobny proces, który aktualizuje stan na przykład z „otrzymane” na „przetwarzane” i „zakończone”. Taki model wymaga jednak obsługi awarii pomiędzy poszczególnymi etapami. Ponowiona dostawa nie powinna tworzyć nowego zadania, jeżeli identyczne zdarzenie ma już zapisany stan zakończony. Jeżeli poprzednie przetwarzanie przerwało się, system może wznowić je według zdefiniowanej polityki, ale nie powinien bezwarunkowo wykonywać wszystkich skutków od początku.

Idempotencja nie zawsze oznacza całkowity brak ponownego wykonania kodu. Oznacza, że wielokrotne przyjęcie tego samego zdarzenia prowadzi do tego samego końcowego stanu, a nie do wielokrotnego skutku ubocznego. Aktualizacja rekordu do wartości „opłacone” może być idempotentna, natomiast bezpośrednie dodanie kolejnej pozycji do tabeli, wysłanie kolejnego powiadomienia lub zwiększenie licznika może wymagać dodatkowego klucza deduplikacyjnego. W logach warto rejestrować identyfikator zdarzenia, identyfikator próby dostarczenia, wynik weryfikacji, czas rozpoczęcia i zakończenia oraz powód ewentualnego ponowienia. Ułatwia to odróżnienie rzeczywistego duplikatu od dwóch różnych zdarzeń o podobnych danych.

Sprawdzenie działania webhooka na komputerze

Podczas diagnozowania integracji na laptopie lub komputerze PC należy najpierw ustalić, czy powtórzenia występują po stronie nadawcy, czy dopiero w lokalnym programie odbierającym żądania. Pomocne jest porównanie identyfikatorów zdarzeń, znaczników czasu oraz kodów odpowiedzi HTTP. Jeżeli identyfikator pozostaje taki sam, prawdopodobnie chodzi o ponowną dostawę tego samego zdarzenia. Jeżeli identyfikatory są różne, trigger mógł utworzyć kilka zdarzeń albo aplikacja pośrednia zmieniła komunikat. Należy również sprawdzić, czy program nie uruchamia dwóch instancji nasłuchujących na tym samym adresie, czy zadanie nie jest wywoływane przez kilka harmonogramów oraz czy błąd nie powoduje ponownego wysłania żądania.

Warto przejrzeć logi aplikacji razem z logami systemu, zapory sieciowej i narzędzia odpowiedzialnego za integrację. Samo usunięcie powtarzających się wpisów z logu nie rozwiązuje problemu, jeżeli aplikacja nadal wykonuje operację biznesową wiele razy. Sprawdzenie powinno obejmować także zegar systemowy, certyfikaty TLS, konfigurację adresu endpointu, limity czasu oraz sposób zwracania odpowiedzi. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, więc w przypadku problemów z lokalnym środowiskiem, systemem lub działaniem programu na komputerze można rozpocząć od diagnostyki urządzenia i jego konfiguracji.