brak odbiornika webhooka

Brak odbiornika webhooka to usterka architektury pozbawionej punktu końcowego przyjmującego powiadomienia HTTP.

Na czym polega brak odbiornika webhooka

Webhook jest mechanizmem przekazywania zdarzenia przez żądanie HTTP wysyłane z jednego systemu do drugiego. System źródłowy, na przykład aplikacja obsługująca płatność, repozytorium kodu albo narzędzie automatyzacji, wysyła powiadomienie pod określony adres URL. Brak odbiornika webhooka oznacza, że po stronie docelowej nie istnieje działający punkt końcowy, który mógłby takie żądanie przyjąć, rozpoznać i przetworzyć.

Usterka może wystąpić także wtedy, gdy adres został skonfigurowany, ale wskazuje nieistniejącą ścieżkę, nieuruchomiony proces albo usługę nasłuchującą na innym porcie. Z punktu widzenia nadawcy skutkiem jest zwykle odpowiedź HTTP 404, 405, 502 lub 503, przekroczenie limitu czasu albo całkowity brak połączenia. Samo wygenerowanie zdarzenia przez system źródłowy nie oznacza więc, że informacja dotarła do aplikacji docelowej.

Jak powiadomienie przechodzi przez system

Prawidłowy przepływ obejmuje kilka niezależnych elementów. Nadawca musi utworzyć żądanie HTTP, najczęściej metodą POST, i skierować je pod właściwy adres. Następnie połączenie musi przejść przez sieć, rozwiązywanie DNS, zaporę sieciową, serwer HTTP lub reverse proxy oraz aplikację udostępniającą trasę webhooka. Odbiornik powinien odebrać nagłówki i treść żądania, sprawdzić ich poprawność, a następnie zwrócić odpowiedź wskazującą, czy żądanie zostało przyjęte.

Brak odbiornika przerywa ten łańcuch na poziomie punktu końcowego. Jeżeli aplikacja nie ma zdefiniowanej trasy, serwer może zwrócić kod 404 Not Found. Kod 405 Method Not Allowed wskazuje, że ścieżka istnieje, ale nie zezwala na użyteczną metodę HTTP. Błąd 502 Bad Gateway lub 503 Service Unavailable może oznaczać problem pomiędzy proxy a procesem aplikacji albo niedostępność samego procesu. Czasami połączenie jest odrzucane jeszcze wcześniej, na przykład przez zamknięty port lub regułę zapory.

Objawy i metody potwierdzenia usterki

Najbardziej charakterystycznym objawem jest brak reakcji w aplikacji, która powinna wykonać działanie po nadejściu zdarzenia. Przykładowo zmiana stanu w systemie źródłowym może nie uruchomić synchronizacji, zadania automatycznego lub aktualizacji lokalnego programu. W panelu nadawcy mogą pojawić się nieudane próby dostarczenia, kody odpowiedzi HTTP, komunikaty o przekroczeniu czasu oczekiwania albo seria ponowień wysyłki. Jeżeli nadawca nie rejestruje żadnej próby, problem może leżeć jeszcze przed wysłaniem webhooka.

Diagnostyka powinna rozpocząć się od porównania skonfigurowanego adresu URL z rzeczywistą trasą aplikacji. Należy sprawdzić nazwę hosta, protokół HTTP lub HTTPS, port, ścieżkę oraz ewentualne przekierowania. Następnie można przeanalizować logi serwera WWW, reverse proxy i aplikacji, zwracając uwagę na czas żądania, metodę, kod odpowiedzi i długość przetwarzania. Test wysłany kontrolnie powinien trafić do tego samego adresu i używać formatu danych oczekiwanego przez odbiornik. Samo otwarcie adresu w przeglądarce nie jest wystarczającym testem, ponieważ przeglądarka zazwyczaj wysyła żądanie GET, a webhook może akceptować wyłącznie POST.

Ważne jest również rozróżnienie pomiędzy brakiem odbiornika a błędem jego obsługi. Jeżeli log aplikacji pokazuje odebrane żądanie, punkt końcowy istnieje, a przyczyny należy szukać w walidacji danych, autoryzacji, mapowaniu pól lub dalszym przetwarzaniu. Jeżeli żądanie nie pojawia się w logach serwera, trzeba sprawdzać adres, sieć, proxy i routing. Taki podział ogranicza ryzyko poprawiania kodu aplikacji, do której powiadomienie w ogóle nie dociera.

Przywrócenie ciągłości dostarczania zdarzeń

Usunięcie problemu wymaga utworzenia właściwej trasy webhooka albo przywrócenia procesu, który ją udostępnia. Konfiguracja powinna wskazywać aktualny adres, a serwer musi przyjmować metodę i format używany przez nadawcę. Po zmianie należy wykonać kontrolne dostarczenie zdarzenia oraz potwierdzić jego obecność w logach i poprawne zakończenie dalszego przepływu danych. Jeżeli nadawca stosuje ponowienia, trzeba sprawdzić, czy odpowiedź błędna nie powoduje wielokrotnego wykonania tej samej operacji.

W przypadku komputera, na którym działa lokalny odbiornik, należy dodatkowo zweryfikować uruchomienie aplikacji, nasłuchiwanie na właściwym interfejsie i porcie, reguły zapory oraz dostępność urządzenia z sieci, z której przychodzą żądania. Nie powinno się zakładać, że adres localhost będzie dostępny dla zewnętrznego nadawcy, ponieważ oznacza on komputer wykonujący dane połączenie. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, w tym diagnostyką problemów z działaniem aplikacji oraz połączeń sieciowych na używanym sprzęcie.

Po przywróceniu odbiornika warto sprawdzić kilka różnych zdarzeń, a nie tylko pojedynczy test. Potwierdzenia powinny obejmować odebranie żądania, poprawną odpowiedź HTTP, zapis zdarzenia oraz wykonanie oczekiwanej operacji. Dzięki temu można odróżnić chwilową dostępność adresu od rzeczywiście działającego przepływu webhooka.