200 OK, które nic nie znaczyło

Ciao! 🇵🇱🇮🇹

23 lipca poprawiałem jedno pole na 142 pokojach w systemie do zarządzania najmem, i serwer przez chwilę udawał, że wszystko poszło dobrze.

Kod 200 potrafi kłamać spokojniej niż jakikolwiek błąd.

Lecimy z tematem 🚀

200 OK, które nic nie znaczyło

23 lipca chciałem poprawić jedno pole, deposit_required, na 142 pokojach w SON, systemie do zarządzania najmem, którego używamy w Ultra. Chodziło o wyrównanie kaucji do wysokości czynszu tam, gdzie te dwie liczby się rozjechały, drobna zmiana na pierwszy rzut oka. Endpoint odpowiadał błędem 500 na każdy request, więc zgłoszenie do supportu poszło tego samego dnia.

Etap 1: naprawa, która nie naprawiła

Kilka dni później dostałem informację, że poprawka jest wgrana. Endpoint faktycznie przestał zwracać 500, każdy PATCH kończył się teraz kodem 200, dokładnie tak jak powinien. Problem w tym, że pole deposit_required po prostu się nie zapisywało, mimo tego pozornie czystego sukcesu. Na tym samym payloadzie inne pole, expected_rent, zapisywało się bez zarzutu, więc na pierwszy rzut oka wszystko wyglądało w porządku, i łatwo byłoby uznać sprawę za zamkniętą.

Etap 2: zaufaj, ale sprawdź

Zamiast uwierzyć na słowo, wybrałem dwa pokoje, wysłałem PATCH z wartością testową inną niż ta, która już tam była, i zaraz potem odpytałem te same pokoje osobnym zapytaniem GET. Dopiero ten drugi krok, re-fetch zaraz po zapisie, pokazał prawdę: kod 200, a wartość w bazie ani drgnęła. Gdybym poprzestał na samej odpowiedzi z PATCH, cały bulk-fix poszedłby na setkach rekordów, które wyglądałyby na naprawione, a realnie zostałyby dokładnie takie jak przed poprawką.

Etap 3: bulk-fix z pełną nieufnością

Po drugim zgłoszeniu i drugiej poprawce ten sam test na tych samych dwóch pokojach w końcu przeszedł. Dopiero wtedy uruchomiłem skrypt na całym portfelu, sto czterdzieści dwa pokoje, z jednym zastrzeżeniem: re-fetch po każdym pojedynczym PATCH, nie po próbce kilku rekordów na końcu. Zajęło to dłużej niż sam bulk-fix, ale dwa razy z rzędu ten sam endpoint dał fałszywy sukces z dwóch różnych powodów, więc próbka przestała mi wystarczać.

Kod 200 mówi tylko, że serwer odebrał request i się nie wywalił. Nie mówi nic o tym, czy dane faktycznie trafiły tam, gdzie miały trafić.

🛠️ Narzędzie

PostHog

Narzędzie do śledzenia realnych zdarzeń w aplikacji, nie tylko tego czy serwer odpowiada. W CelneCV podłączyłem je przez MCP wprost do rozmowy z Claude, więc pytanie o konkretne zdarzenie użytkownika (rejestracja, wysłana aplikacja) dostaje odpowiedź opartą na tym, co faktycznie się wydarzyło, a nie na tym, co powinno się wydarzyć według kodu. Polecam z tego samego powodu co re-fetch po PATCH: status „wdrożone” i status „działa dla użytkownika” to dwa różne pytania.

posthog.com

🌍 Ze świata

• Google nixes its Earth AI feature one day after launch, amid criticism it would spread misinformation. Funkcja zadziałała technicznie bez zarzutu, a mimo to trzeba było ją zdjąć dzień później, bo nikt wcześniej nie zapytał, co z nią zrobią ludzie.

• The Most Dangerous Response Code Isn’t 500. It’s 200.. Sześć wzorców tego samego zjawiska, które opisuję wyżej, tylko po stronie frontendu i CDN-ów zamiast bazy danych.

• Catching Silent API Failures: A Micro-Lab. Ktoś zbudował sobie osobne narzędzie tylko po to, żeby robić w pętli to, co ja robiłem ręcznie przy 142 pokojach.

😄 Na koniec

Drugie zgłoszenie do supportu SON miało dokładnie ten sam klimat. Sprawa mnie nie dotyczyła, a mimo to musiałem tam być.

Jeśli ktoś w Twoim otoczeniu powinien to przeczytać, prześlij mu ten numer. To najlepsza forma wsparcia.