konflikt danych przy wielu webhookach

Konflikt danych przy wielu webhookach to sytuacja, w której równoległe powiadomienia nadpisują się nawzajem.

Jak powstaje konflikt danych przy równoległych webhookach

Konflikt danych przy wielu webhookach pojawia się wtedy, gdy kilka systemów wysyła powiadomienia dotyczące tego samego obiektu, a odbiorca przetwarza je w tym samym czasie albo w kolejności innej niż kolejność wystąpienia zdarzeń. Webhook jest żądaniem HTTP wysłanym zwykle metodą POST do wskazanego adresu URL. Przenosi dane zdarzenia, na przykład identyfikator zamówienia, status płatności, numer wersji rekordu lub znacznik czasu. Jeżeli dwa powiadomienia zmieniają ten sam rekord, późniejszy zapis może nadpisać wcześniejszy, nawet gdy zawiera starszy stan.

Przykładowo system źródłowy może najpierw wygenerować zdarzenie „urządzenie odłączone”, a chwilę później „urządzenie ponownie podłączone”. Jeżeli webhook dotyczący ponownego podłączenia zostanie opóźniony, a odbiorca nie sprawdza numeru sekwencyjnego lub aktualności danych, może najpierw zapisać stan aktywny, a następnie zastąpić go stanem nieaktywnym. Podobny problem występuje, gdy dwa żądania aktualizujące pola tego samego rekordu wykonują się równolegle i oba odczytują tę samą starą wartość przed zapisaniem własnego wyniku.

Wyścig zapisów, kolejność zdarzeń i utracone aktualizacje

Jednym z typowych mechanizmów konfliktu jest tak zwany race condition, czyli zależność wyniku od kolejności wykonania operacji. Dwa procesy obsługi webhooków mogą jednocześnie odczytać rekord z wartością „oczekuje”, przygotować różne zmiany i wykonać zapisy. Jeżeli zapis obejmuje cały obiekt, a nie tylko zmienione pola, druga operacja może usunąć zmianę wprowadzoną przez pierwszą. Taki przypadek jest nazywany utraconą aktualizacją. Sam fakt, że oba żądania zakończyły się kodem HTTP 200, nie oznacza, że końcowy stan danych jest prawidłowy.

Nie każdy dostawca webhooków gwarantuje kolejność dostarczania powiadomień. Ponadto dostawca może ponowić wysłanie połączenia, gdy odbiorca odpowie z błędem, przekroczy limit czasu albo połączenie zostanie przerwane. Odbiorca może więc otrzymać to samo zdarzenie więcej niż raz oraz dostać zdarzenia w innej kolejności. Bez identyfikatora zdarzenia, kontroli wersji i reguły rozstrzygania starszych powiadomień aplikacja nie odróżni nowej zmiany od powtórzonego lub spóźnionego komunikatu.

Idempotencja i kontrola wersji w obsłudze powiadomień

Podstawowym zabezpieczeniem jest idempotentne przetwarzanie webhooków. Oznacza to, że wielokrotne zastosowanie tego samego powiadomienia nie zmienia wyniku po pierwszym poprawnym przetworzeniu. Aplikacja może zapisać unikalny identyfikator zdarzenia w tabeli przetworzonych komunikatów i przed rozpoczęciem operacji sprawdzić, czy identyfikator już wystąpił. Kontrola musi być wsparta unikalnym ograniczeniem w bazie danych, ponieważ dwa równoległe procesy mogą wykonać sprawdzenie w tej samej chwili.

Drugim mechanizmem jest optymistyczna kontrola współbieżności. Rekord może zawierać numer wersji albo monotoniczny numer zdarzenia. Aktualizacja jest wykonywana tylko wtedy, gdy wersja odczytana przez proces nadal odpowiada wersji zapisanej w bazie. W przeciwnym razie operacja kończy się konfliktem i może zostać ponowiona po ponownym odczycie. W systemach, w których kolejność ma znaczenie, pomocne jest także szeregowanie komunikatów według identyfikatora obiektu, aby zdarzenia dotyczące tego samego rekordu trafiały do jednego uporządkowanego strumienia.

Sprawdzenie przepływu webhooków na laptopie i komputerze

Diagnozę warto rozpocząć od zebrania identyfikatorów żądań, czasu przyjęcia, kodu odpowiedzi, czasu przetwarzania oraz identyfikatora zmienianego obiektu. W logach należy porównać kolejność nadejścia webhooków z kolejnością utworzenia zdarzeń u nadawcy. Trzeba również sprawdzić, czy ponowienia są rozpoznawane, czy aplikacja odpowiada przed zakończeniem ciężkiej operacji oraz czy błędy zapisu nie powodują potwierdzenia komunikatu jako obsłużonego. Przydatne jest odtworzenie dwóch żądań równolegle w środowisku testowym i porównanie końcowego stanu rekordu z oczekiwaną sekwencją zmian.

Na komputerze użytkownika problem może być widoczny jako nieaktualny status w panelu, znikające ustawienie, powracająca konfiguracja albo rozbieżność między aplikacją i usługą internetową. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a w ramach diagnostyki oprogramowania można także sprawdzić lokalne logi klienta, stabilność połączenia, synchronizację zegara oraz wersję aplikacji odpowiedzialnej za odbiór powiadomień. Sama naprawa komputera nie rozwiąże błędu występującego w logice zdalnego odbiorcy webhooków, dlatego ustalenie miejsca powstawania konfliktu wymaga rozdzielenia problemu lokalnego od błędu po stronie usługi.