Il bug peggiore non rompe la funzione: rompe la vista

Risposta diretta: il bug più difficile da trovare non è quello che rompe una funzionalità — quello lo segnala subito qualcuno. È quello che rompe la vista sulla funzionalità: tutto funziona, ma l'interfaccia dice di no. Sopravvive per mesi perché chi ha i permessi per notarlo (l'amministratore) non attraversa mai il codice rotto, e chi lo vedrebbe (un utente normale) non lo interpreta come un guasto ma come «non l'ho ancora configurato bene».

TL;DR

• 26 strumenti collegati, testati dal vivo in produzione con dati reali. Tutti funzionanti.
• La pagina di configurazione ne mostrava zero, come se niente fosse collegato.
• Causa: il codice che decide quali strumenti mostrare gestiva solo i casi già visti (le piattaforme e-commerce note). Un gruppo di strumenti che si attiva con un meccanismo diverso cadeva in un ramo che non esisteva.
• Lo stesso bug era già presente da prima per un altro gruppo di strumenti. Nessuno se n'era accorto.
• Il motivo per cui era sopravvissuto: chi lo aveva sempre configurato lo faceva da account amministratore, che vede tutto per definizione e quindi non passa mai dal ramo rotto.
• Regola operativa: testa sempre con l'account meno privilegiato, non con il tuo.

La situazione

Avevo appena finito di collegare 26 strumenti a un assistente conversazionale: ricerca di norme, progetti PNRR, sentenze, dati parlamentari. Li avevo verificati uno per uno, dal vivo, in produzione, contro dati reali. Funzionavano.

Poi ho aperto la pagina in cui si configura l'assistente — quella dove scegli quali strumenti mettergli a disposizione — e mostrava zero strumenti disponibili. Come se non avessi collegato niente.

Questa è la fase in cui la maggior parte delle persone perde mezza giornata, perché il sistema ti sta dando due informazioni opposte e nessuna delle due è ovviamente sbagliata.

Dove stava il problema

Il codice che risponde alla domanda «quali strumenti posso mostrare a chi sta configurando questo assistente» era scritto come una serie di casi noti:

• se il cliente ha un negozio su una certa piattaforma → mostra questi strumenti
• se ha un negozio su un'altra piattaforma → mostra quest'altri
• se ha una configurazione specifica → mostra quelli

I miei strumenti si attivavano con un meccanismo diverso: un gruppo unico, indipendente dalla piattaforma e-commerce, per il semplice motivo che quel prodotto non vende niente. Nessuno dei rami esistenti sapeva cosa fare con «non è un negozio».

Il risultato: il mio gruppo cadeva nel vuoto. Non un errore, non un'eccezione, non un log. Semplicemente una lista vuota, restituita con la stessa serenità con cui sarebbe stata restituita una lista piena.

La funzionalità era integra. Era rotta solo la risposta alla domanda «cosa c'è?».

Il bonus: c'era già, per qualcun altro

Qui la storia diventa interessante. Indagando ho scoperto che lo stesso identico bug esisteva già da prima per un altro gruppo di strumenti — quelli del tracking spedizioni. Stessa causa, stesso ramo mancante, stesso sintomo.

Era lì da mesi. Nessuno l'aveva mai segnalato.

Il motivo è la parte che vale la pena portarsi via: chi aveva configurato quel prodotto lo aveva sempre fatto con un account amministratore. E un amministratore, per definizione, vede tutto: il codice che filtra gli strumenti per tenant non viene nemmeno attraversato, perché c'è un ramo precedente che dice «sei admin, ecco tutto».

Quindi le due categorie di persone che avrebbero potuto accorgersene erano entrambe cieche, per motivi opposti:

Chi	Perché non lo vede
Amministratore (chi sviluppa, chi fa il setup)	Salta il ramo rotto: vede sempre tutto
Utente normale (il cliente)	Vede la lista vuota, ma pensa «non l'ho ancora configurato»

Il cliente non segnala un bug di sistema: segnala, al massimo, una propria incompetenza — e più spesso non segnala affatto, ci rinuncia.

Perché questa classe di bug è così longeva

Un bug che rompe una funzionalità ha un ciclo di vita breve: qualcuno prova a fare una cosa, non funziona, lo dice. Il feedback è immediato e inequivocabile.

Un bug che rompe la vista ha tre proprietà che lo rendono quasi immortale:

1. Non produce errori. Una lista vuota è una risposta legittima. Nessun log, nessun alert, nessuna traccia.
2. È invisibile a chi sviluppa, perché chi sviluppa gira con permessi pieni.
3. Viene interpretato come colpa dell'utente da chi lo subisce, e quindi non risale mai.

Aggiungi che i test automatici, quando esistono, sono quasi sempre scritti con l'utente di test più comodo — cioè quello con tutti i permessi — e hai un buco che si autoconserva.

Cosa faccio da allora

• Il percorso critico si testa con l'account meno privilegiato che esiste. Non con il tuo. Se la tua applicazione ha ruoli, il test di accettazione gira sul ruolo più basso che deve poter fare quella cosa.
• Una lista vuota è un caso da trattare, non un default. Se una funzione può legittimamente restituire zero elementi, l'interfaccia deve distinguere «non ce n'è» da «non lo so»: sono due stati diversi e meritano due messaggi diversi.
• Quando trovi un ramo mancante, cerca chi altro ci casca. Un if che gestisce solo i casi noti raramente ne penalizza uno solo. Nel mio caso il secondo era lì da mesi, ed è saltato fuori solo perché stavo guardando in quella direzione.
• Diffida della coppia «funziona ma non si vede». È quasi sempre un problema di autorizzazioni o di enumerazione, quasi mai di logica di business.

C'è anche un punto più generale sul lavorare in fretta con l'AI: quando generi molto codice rapidamente, i rami mancanti si moltiplicano più dei bug espliciti, perché un'omissione non rompe niente e quindi non si fa notare. È il motivo per cui la disciplina sui commit e la revisione di cosa non è stato gestito contano più della velocità con cui è stato scritto.

FAQ

Perché un bug di visualizzazione può sopravvivere per mesi?

Perché non genera errori, non è visibile a chi sviluppa (che gira con permessi pieni) e chi lo subisce lo interpreta come una propria mancanza di configurazione invece che come un guasto. Mancano tutti e tre i canali con cui un bug normale viene segnalato.

Cosa significa «testare con l'account meno privilegiato»?

Significa eseguire le verifiche di accettazione con il ruolo più basso che deve poter compiere quell'azione, non con l'account di amministrazione che usi per sviluppare. È l'unico modo per attraversare i rami di codice che filtrano per permessi.

Come si distingue «non ci sono elementi» da «non riesco a leggerli»?

Trattandoli come due stati diversi già nel backend e rendendoli distinguibili nell'interfaccia. Una lista vuota restituita con successo e una lista vuota perché il filtro non ha saputo classificare il caso devono produrre messaggi diversi per chi legge.

È un problema tipico dei sistemi multi-tenant?

È più frequente lì, perché la logica «quali cose vede questo cliente» è proprio il punto in cui si annidano i rami mancanti. Ma capita ovunque ci siano ruoli e permessi: basta un if scritto sui casi conosciuti al momento.

---

Se hai un sistema dove «funziona ma non si vede» succede più di una volta, di solito il problema non è nel singolo bug ma in come sono organizzati permessi ed enumerazione. Parliamone — è il tipo di revisione che faccio spesso come Fractional CTO.