Errori e bug · 6 min di lettura ·
Errori Supabase più comuni: cosa significano e come risolverli
Permission denied, JWT expired, relation does not exist, Failed to fetch: gli errori Supabase più comuni nelle app fatte con l'AI, spiegati in modo semplice.
Se la tua app fatta con l'AI usa Supabase e qualcosa si è rotto, il messaggio d'errore contiene già quasi tutta la risposta: va solo tradotto. In questa guida spieghiamo in parole semplici gli errori Supabase più comuni, come permission denied for table, JWT expired, relation does not exist e Failed to fetch: cosa significano davvero e cosa puoi controllare da solo prima di chiedere all'AI di riscrivere il codice.
Cos'è Supabase e perché gli errori arrivano da lì
Supabase è il backend usato da molte app create con Lovable, Bolt e altri strumenti AI. Il backend è la parte dell'app che non vedi: il database dove stanno i dati, il sistema di login, lo spazio per i file. Il frontend, cioè l'interfaccia nel browser, parla con Supabase attraverso un'API, una specie di sportello a cui inviare richieste.
A quello sportello c'è un controllore: le regole RLS (Row Level Security, «sicurezza a livello di riga»), che decidono chi può leggere o modificare ogni singola riga di una tabella. Molti errori nascono qui: la richiesta arriva, ma il controllore dice di no. Altri nascono prima ancora di arrivare allo sportello, per un indirizzo sbagliato o una chiave mancante.
Dove leggere l'errore completo
Prima di tutto serve il messaggio esatto, non il riassunto che compare nell'app.
- Apri l'app nel browser e premi F12.
- Nella scheda «Console» cerca i messaggi in rosso.
- Nella scheda «Network» (Rete) clicca sulla richiesta fallita verso l'indirizzo del tuo progetto Supabase e guarda la risposta: di solito contiene un
code, unmessagee a volte unhint, cioè un suggerimento. - Nel pannello di Supabase apri la sezione dei log: lì trovi le richieste fallite viste dal lato del server.
Gli errori Supabase più comuni, uno per uno
permission denied for table ...
Il ruolo con cui l'app accede al database non ha il permesso di usare quella tabella. Il codice dell'errore è 42501, lo stesso usato per altri problemi di permessi. Succede spesso quando una tabella è stata creata a mano o da uno script senza concedere i permessi di base, oppure quando l'app prova a usare una tabella che non dovrebbe essere raggiungibile dal browser.
La tentazione è chiedere all'AI di «dare tutti i permessi» o di disattivare i controlli. Non farlo: rischi di rendere i dati leggibili da chiunque. Spieghiamo come impostare correttamente le regole nella guida su Supabase e la RLS.
new row violates row-level security policy for table ...
Stai provando a inserire o modificare una riga e la regola RLS lo vieta. Di solito manca una regola che consenta l'inserimento, oppure la regola esiste ma richiede che l'utente sia loggato o che la riga gli appartenga, e la richiesta non soddisfa la condizione. Per esempio, la riga viene salvata senza l'identificativo dell'utente che la crea.
La query non dà errori ma restituisce un elenco vuoto
Questo non è un messaggio d'errore, ed è proprio per questo che confonde. Quando la RLS non consente di leggere certe righe, Supabase non segnala un errore: semplicemente non le restituisce. Se i dati ci sono nel pannello ma l'app non li mostra, quasi sempre manca una regola di lettura o è troppo restrittiva.
JWT expired
Il JWT è il «badge» digitale che l'utente riceve quando fa il login: a ogni richiesta l'app lo mostra a Supabase per dire chi è. Questo badge ha una scadenza. Normalmente la libreria di Supabase lo rinnova da sola, ma l'errore compare se il codice salva il badge a mano e continua a usare quello vecchio, se la scheda è rimasta aperta a lungo in background o se l'orologio del dispositivo è molto sbagliato. Se l'errore si ripete spesso, il problema è nella gestione della sessione: ne parliamo nella guida sugli errori di login e autenticazione.
relation "public.nome_tabella" does not exist
«Relation» qui significa tabella: il database non trova la tabella che il codice sta cercando (codice 42P01). Una variante che ricevi attraverso l'API è Could not find the table 'public.nome_tabella' in the schema cache (codice PGRST205). Le cause tipiche:
- la tabella non è mai stata creata in questo progetto, per esempio perché una modifica al database fatta in sviluppo non è stata applicata in produzione;
- l'app punta a un progetto Supabase diverso da quello che stai guardando;
- il nome è scritto in modo diverso, anche solo per una maiuscola;
- la tabella è stata creata da pochissimo e l'API non l'ha ancora «vista».
Failed to fetch
L'app non è proprio riuscita a raggiungere Supabase. Non è un messaggio di Supabase ma del browser, e le cause più frequenti sono:
- l'indirizzo del progetto nelle variabili d'ambiente è sbagliato o manca online;
- il progetto è in pausa: sul piano gratuito Supabase mette in pausa i progetti con poca attività nell'arco di una settimana, e va riattivato dal pannello;
- una Edge Function (una piccola funzione che gira sui server di Supabase) blocca la richiesta per un problema di CORS, che spieghiamo nella guida sull'errore CORS;
- un'estensione del browser, come un blocco pubblicità, ferma la richiesta.
Invalid API key o 401 Unauthorized
La chiave che l'app usa per presentarsi a Supabase è sbagliata, è stata rigenerata o non è stata impostata sull'hosting, cioè sul servizio che tiene online l'app. Controlla che online ci sia la chiave pubblica del progetto giusto. Attenzione a non «risolvere» mettendo nel frontend la chiave segreta di servizio (service_role): quella scavalca tutte le regole di sicurezza e non deve mai finire nel browser. Il perché lo spieghiamo nella guida sulle chiavi API esposte.
duplicate key value violates unique constraint
Stai inserendo un valore che deve essere unico e che esiste già, per esempio un secondo profilo per lo stesso utente o un'email già registrata. Di solito il codice crea la stessa riga due volte: magari il pulsante viene premuto due volte, oppure sia l'app sia un automatismo del database provano a creare il profilo.
Riepilogo: errore, significato, prima verifica
| Errore | Cosa significa | Prima cosa da controllare |
|---|---|---|
permission denied for table | Mancano i permessi sulla tabella | Permessi e regole RLS della tabella |
new row violates row-level security policy | La RLS vieta l'inserimento | Regola di inserimento e utente loggato |
| Elenco vuoto senza errori | La RLS filtra la lettura | Regola di lettura (SELECT) |
JWT expired | Sessione scaduta non rinnovata | Gestione della sessione nel codice |
relation ... does not exist | Tabella inesistente | Progetto giusto, nome, modifiche applicate |
Failed to fetch | Supabase non raggiungibile | URL, progetto in pausa, CORS |
Invalid API key / 401 | Chiave errata o mancante | Variabili d'ambiente sull'hosting |
duplicate key value | Valore unico già presente | Codice che crea la riga due volte |
Cosa puoi fare tu
- Copia il messaggio completo, con codice e suggerimento, dalla scheda Network.
- Verifica di guardare il progetto giusto: confronta l'indirizzo nelle variabili d'ambiente con quello nel pannello di Supabase.
- Non disattivare la RLS per far sparire un errore. Se serve, chiedi all'AI di proporre la regola mancante e di spiegarti chi potrà leggere o scrivere quei dati.
- Fai un backup prima di modificare il database, soprattutto se ci sono dati di utenti reali.
- Chiedi una correzione mirata, incollando l'errore e indicando la tabella e l'azione: lettura, inserimento o modifica.
Quando conviene farti aiutare
Gli errori di Supabase toccano dati e permessi, cioè le parti dove uno sbaglio costa di più. Se per risolvere servirebbe allentare le regole di sicurezza, se l'app ha già utenti reali o se l'errore cambia ogni volta che l'AI ci mette le mani, conviene far controllare la configurazione a qualcuno che conosce bene Supabase.
Di solito verifichiamo regole RLS, permessi e variabili d'ambiente, sistemiamo la causa e ti lasciamo una spiegazione chiara di cosa è cambiato. Se vuoi guardarci insieme, prenota una call gratuita di 20 minuti.
