Un export Telegram che diventa "[object Object]": quando l'input non validato rompe il tuo codice

Un campo che sembra testo ma è un array: il bug silenzioso che nessuno prevede

In un progetto tecnico raccontato su dev.to l'autore descrive un dettaglio che sembra banale ma che spacca tutto: nell'export JSON di Telegram, il campo text di un messaggio non è sempre una stringa. Un messaggio normale contiene text: "ciao", ma un messaggio con un link o una parte in grassetto diventa un array di frammenti misti, oggetti e stringhe.

Risultato: chiamare String(msg.text) su quella struttura produce un innocuo [object Object] piantato in mezzo al contenuto. Nessun errore, nessun crash. Solo dati corrotti che passano inosservati finché non è troppo tardi.

Questo è il tipo di problema che non esplode in fase di test, perché su un export piccolo non capita mai un messaggio formattato. Esplode in produzione, sui dati reali.

Cosa significa se il tuo codice l'ha scritto Lovable

Se hai costruito la tua app con Lovable partendo da un prompt tipo "importa i dati dell'utente e mostrali in dashboard", quasi sicuramente il codice generato assume che ogni campo abbia la forma più semplice possibile. Una stringa è una stringa, un numero è un numero, un oggetto ha sempre le stesse chiavi.

È un'assunzione ragionevole per una demo. È un problema serio quando l'input arriva da un file caricato, da una API esterna, da un webhook o da un utente reale.

Gli strumenti AI producono codice che gestisce bene il caso felice. Il caso in cui l'utente carica esattamente il file previsto, con esattamente i campi previsti, nel formato previsto. Ma il mondo reale manda strutture annidate, campi opzionali, tipi che cambiano, valori null dove ti aspettavi una stringa.

Quando il tuo codice non valida l'input prima di usarlo, hai due esiti possibili. Nel migliore dei casi l'app va in crash e te ne accorgi. Nel peggiore, come nell'esempio dell'export Telegram, il dato viene silenziosamente corrotto e finisce nel database, nella dashboard o nel report che mostri ai tuoi clienti.

Perché ora ti serve un audit

Il punto non è che hai usato l'AI. Il punto è che nessuno ha ancora emesso un verdetto sul comportamento del tuo codice quando riceve un input diverso da quello immaginato.

Un audit non serve a farti sentire in colpa per aver generato il progetto in un pomeriggio. Serve a rispondere a una domanda precisa: dove il tuo codice si fida ciecamente di un dato esterno senza verificarne la forma?

È una domanda che tu, da solo, fatichi a rispondere. Non perché non sei capace, ma perché non conosci ogni riga del codice che l'AI ha scritto per te. Molti di quei parser, di quelle funzioni che trasformano JSON in oggetti, di quei punti in cui un campo viene dato per scontato, sono nati da un prompt e non sono mai stati letti da un occhio critico.

Con VibeInspect carichi lo ZIP del repository e ricevi un'analisi con specialisti AI e un PDF con il verdetto. Nessun server coinvolto: il codice sorgente viene cancellato al termine dell'analisi. Non è un pentest, non corregge il codice al posto tuo e non promette sicurezza assoluta. Ti dice in che stato è il tuo progetto, con evidenze concrete su cui lavorare.

Per un problema tecnico specifico come la validazione dell'input, il piano Diagnostic ti indica file, riga ed evidenze, così sai esattamente dove intervenire.

Cosa un linter non vede

È facile pensare: "ho già un linter, mi accorgerei di questi problemi". Non è così.

Un linter controlla lo stile del codice, le variabili non usate, l'indentazione, qualche pattern rischioso a livello sintattico. È utile, ma lavora sulla forma, non sul comportamento.

Un linter non sa che il campo text di un export Telegram a volte è una stringa e a volte un array. Non conosce il formato dei dati che entrano nella tua applicazione. Non capisce che quella chiamata a String() produrrà un [object Object] corrotto quando l'input avrà una forma diversa.

Questa è la distinzione che conta:

• Il linter vede che il tuo codice è scritto in modo pulito.
• L'audit vede che il tuo codice si comporta male quando riceve un input dalla forma inattesa.

Anche i type checker aiutano solo fino a un certo punto. Se dichiari che un campo è una stringa ma il file reale contiene un array, il tipo dichiarato è una bugia che il compilatore non può smascherare. Il controllo vero avviene a runtime, sui dati reali, ed è lì che serve validazione esplicita.

Lo stesso vale per ogni punto in cui il tuo codice riceve qualcosa dall'esterno: parametri di una query, corpo di una richiesta, payload di un webhook, contenuto di un file caricato. Ognuno di questi è un confine dove il codice generato dall'AI tende a fidarsi troppo.

Cosa fare questa settimana

Non serve riscrivere tutto. Serve iniziare dai confini, i punti in cui un dato esterno entra nel tuo sistema.

1. Elenca ogni punto dove la tua app riceve dati che non controlli: upload di file, chiamate a API di terze parti, webhook, form utente.
2. Per ognuno, verifica se il codice controlla il tipo e la forma del dato prima di usarlo, oppure se lo dà per scontato.
3. Prova a caricare un input volutamente "strano": un campo vuoto, un valore null, un oggetto dove ti aspettavi una stringa. Guarda cosa succede.
4. Se non sai da dove cominciare o il repository è troppo grande per rileggerlo a mano, fai emettere un verdetto esterno.

Un campo che a volte è testo e a volte è un array è il genere di dettaglio che sfugge finché non arriva l'utente giusto con il file sbagliato. Meglio scoprirlo con un audit che con un dato corrotto nel database dei tuoi clienti.

Carica lo ZIP del tuo repository su VibeInspect e ottieni un verdetto con evidenze su dove il tuo codice si fida troppo dell'input.