socorrist.app
Guía de errores
36 errores explicados en cristiano: qué significa cada uno, por qué te pasa, qué no significa y cómo arreglarlo tú mismo. Sin registrarte y sin pagar nada.
Por qué esta guía
Las apps hechas con IA fallan de una manera reconocible, y no es casualidad. Un agente optimiza para que el error desaparezca cuanto antes, así que cuando algo no le deja avanzar toma el atajo que funciona: desactivar una comprobación de seguridad, usar la llave que se salta las reglas, o añadir el prefijo que publica una variable en el navegador. Cada atajo resuelve el problema del momento y deja el siguiente enterrado.
De ahí que los mismos errores se repitan en apps de gente que no se conoce de nada. Y de ahí también que se agrupen en dos familias muy distintas. La primera da la cara: la app se rompe, tú lo ves, y arreglarlo es cuestión de encontrar la causa. La segunda no avisa: la app funciona perfectamente mientras tus datos están al alcance de cualquiera, y solo se descubre si alguien mira.
Cada guía sigue la misma estructura: qué significa el mensaje, por qué te pasa, qué no significa (que suele ser lo que más tranquiliza) y cómo arreglarlo, con los pasos manuales primero y un prompt listo para pegarle a tu agente después.
Grupo A
Tu app no funciona
Algo se ha roto y lo estás viendo. Casi todos tienen arreglo en minutos, una vez sabes cuál de las cuatro causas posibles es la tuya.
- supabaseUrl is requiredTu app está intentando conectarse a Supabase, pero no sabe a qué proyecto. La dirección llega vacía, y la librería de Supabase se para antes de intentarlo siquiera.
- Failed to fetchTu app ha intentado pedir datos a algún sitio y la petición no ha llegado a completarse. El navegador no te dice por qué a propósito: este mensaje es deliberadamente vago por motivos de seguridad, y por eso desespera tanto.
- new row violates row-level security policySupabase ha rechazado guardar una fila. La tabla tiene activada la seguridad por filas, que es lo correcto, pero no hay ninguna regla que diga quién puede escribir en ella. Cuando no hay regla, la respuesta por defecto es que no.
- Pantalla en blanco en producciónTu app se ha publicado, el servidor responde, pero el navegador pinta una página vacía. Casi siempre significa que el JavaScript ha fallado nada más arrancar y se ha parado antes de dibujar nada.
- Missing Supabase environment variablesAlguien puso en tu app una comprobación al arrancar: si no están la dirección y la clave de Supabase, para y avisa. Eso es lo que ha pasado. Y es buena noticia, porque este mensaje es mucho más claro que el que saldría sin esa comprobación.
- Invalid API keyLa petición ha llegado a Supabase, que la ha mirado y ha dicho que no. A diferencia de otros errores, aquí la conexión funciona: lo que no le vale es la credencial que le estás enseñando.
- 403 (Forbidden) en /rest/v1/Supabase ha entendido la petición y sabe quién la hace. Simplemente ha decidido que quien la hace no tiene permiso para ver eso. Si además ves un mensaje que dice permission denied for table, es exactamente lo mismo dicho con otras palabras.
- Auth session missing!Tu app le ha pedido a Supabase los datos del usuario que ha iniciado sesión, y en ese momento no había ninguna sesión abierta. Ojo al matiz: dice que no la hay ahora, no que el usuario no haya entrado nunca.
- La IA no arregla el bug y da vueltas en círculoLe pides que lo arregle, dice que ya está, pruebas y falla igual. Le pasas el error nuevo, cambia otra cosa, y aparece un tercer fallo que antes no existía. No es que lo estés pidiendo mal ni que la herramienta sea mala: es que el agente ya no está resolviendo tu problema, está persiguiendo mensajes de error.
- Environment variable not foundTu app necesita un dato de configuración (una dirección, una clave, un identificador) y ha ido a buscarlo donde debería estar guardado. No estaba. Se para ahí, antes de intentar nada más.
- Deploy failedTu app no ha llegado a publicarse. El servidor intentó construirla, algo se torció por el camino y abortó. La buena noticia inmediata: la versión anterior sigue publicada y funcionando, porque estas plataformas no tiran lo que hay hasta que lo nuevo está listo.
- 500 Internal Server ErrorEl servidor ha recibido la petición, ha intentado responder y se ha caído por el camino. El 500 es el navegador diciéndote que el fallo está del lado del servidor, no en tu conexión ni en tu navegador. Lo que no te dice es cuál, y eso es deliberado: contar los detalles de un error de servidor al visitante sería un problema de seguridad.
- Cannot read properties of undefinedTu código ha intentado leer algo dentro de una caja y la caja no existe. El mensaje suele terminar con el nombre de lo que buscaba: si dice que no puede leer nombre de undefined, tu código pedía el nombre de algo que no había llegado.
- Something went wrongEsto no es el error: es la red de seguridad. Tu app tiene una pantalla preparada para cuando algo falla, para que el visitante no vea una página en blanco ni un mensaje técnico. Ha saltado, así que algo ha fallado por debajo. El mensaje de verdad sigue existiendo, solo que está tapado por esta pantalla.
- El login funciona en el preview pero no en mi dominioTu inicio de sesión no está roto: está protegido. Supabase, y cualquier proveedor de login, solo acepta devolver al usuario a direcciones que tú has declarado de antemano. Tu dominio nuevo no está en esa lista, así que el proceso se corta justo en el momento de volver.
- Stripe webhook 401Cuando alguien te paga, Stripe llama a tu app para avisarla. Tu app está contestando que no está autorizado a hablar, y Stripe se da por vencido. El dinero ha entrado y está en tu cuenta de Stripe; lo que no ha pasado es todo lo que tu app hacía después: dar de alta al cliente, activar su acceso, mandarle el correo.
- Invalid redirect URLTu app le ha pedido al proveedor de identidad que, cuando termine, devuelva al usuario a una dirección concreta. El proveedor ha mirado su lista de direcciones permitidas, no la ha encontrado, y se ha negado. Está haciendo exactamente lo que debe.
- No llega el correo de confirmación, o el enlace no funcionaBajo este síntoma hay dos averías que no se parecen en nada: o el correo no está saliendo, o sí sale y el enlace no completa la sesión al pulsarlo. Antes de tocar nada hay que saber cuál de las dos es, porque se arreglan en sitios distintos.
- Unsupported provider: provider is not enabledTu app le está pidiendo a Supabase que inicie sesión con un proveedor, y Supabase responde que ese método no está activado en tu proyecto. El botón existe en la pantalla; lo que no existe es la puerta que debería abrir.
- La base de datos va lenta o da timeouts con usuarios realesTu app pide datos y la respuesta tarda tanto que algo se cansa de esperar. Lo característico de este problema es que no existía cuando probabas: aparece cuando hay filas de verdad y gente entrando a la vez.
- Failed to load configAntes de funcionar, tu app intenta cargar sus ajustes: a qué servicios se conecta, con qué claves, con qué opciones. Ese paso ha fallado, así que se para antes de empezar. El mensaje no dice cuál de todas las configuraciones es, y ahí está el trabajo.
- No 'Access-Control-Allow-Origin' headerTu app ha pedido datos a otro servidor. El servidor ha contestado, pero sin incluir la cabecera que autoriza a tu web a leer esa respuesta, así que el navegador la ha bloqueado antes de entregártela. La respuesta existe: lo que no existe es el permiso para leerla.
- Unexpected token '<'Tu app pidió datos, esperaba recibirlos en formato de datos, y lo que ha llegado empieza por el símbolo menor que. Eso es HTML: una página web. Está intentando interpretar una página como si fueran datos, y se atraganta en el primer carácter.
- net::ERR_CONNECTION_REFUSEDTu navegador ha intentado conectar y no ha encontrado a nadie al otro lado. No es que la respuesta fuera mala: es que no hubo conversación. La puerta a la que llamó no existe o está cerrada.
- ERR_CERT_AUTHORITY_INVALIDEl navegador ha llegado a tu web, ha mirado su certificado de seguridad y no ha podido comprobar que sea de fiar. Ante la duda, corta y avisa al visitante con una pantalla roja bastante alarmante.
- Module not foundAl construir tu app, el proceso ha encontrado una línea que dice traer algo de un sitio, ha ido a buscarlo y no estaba. Se para ahí: sin esa pieza no puede terminar de montar nada.
- Hydration failedTu página se dibuja dos veces: una en el servidor, para que llegue rápido, y otra en el navegador, para que sea interactiva. Este error dice que las dos versiones no coinciden. El navegador esperaba encontrar una cosa y se ha encontrado otra, así que descarta lo que llegó y lo vuelve a dibujar entero.
- El build falla por errores de TypeScript en cascadaTypeScript comprueba que las piezas de tu código encajan antes de dejar publicar. Ha encontrado sitios donde no encajan y ha parado el despliegue. La sensación de cascada es real, pero engaña: normalmente no son treinta problemas, es uno que se propaga por treinta sitios.
Grupo B
Tu app funciona, y ese es el problema
Fugas de datos que no dan ningún error. No verás nada raro: la app va igual de bien esté abierta o cerrada, y por eso pueden pasar meses sin que nadie lo note.
- La clave service_role de Supabase está en el código públicoSupabase te da dos llaves. Una es pública y va en el navegador a propósito. La otra, la service_role, se salta todas las reglas de seguridad de tu base de datos y solo debe vivir en un servidor. La segunda ha acabado dentro del código que se descarga cualquiera que visite tu web.
- Tengo tablas sin RLS: cualquiera puede leerlasEn Supabase, la clave pública de tu app va en el navegador a propósito, y cualquiera puede leerla. Lo que impide que esa clave sirva para descargarse tus tablas enteras son las políticas de seguridad por filas. Si una tabla no las tiene activadas, esa protección no existe y la tabla está abierta a quien pregunte.
- Política USING (true): acceso abierto a todoTu tabla tiene la seguridad por filas activada, así que el panel de Supabase la da por protegida. Pero la política que la gobierna dice, literalmente, que la condición para acceder es verdadera. O sea: que sí, siempre, a quien sea.
- Puse el prefijo VITE_ o NEXT_PUBLIC_ a un secreto y se publicóEsos prefijos no son un formalismo del nombre: son una instrucción. Le dicen a la herramienta que construye tu app que esa variable debe copiarse dentro del código que se descarga el navegador. Ponerle ese prefijo a un secreto es, literalmente, pedir que se publique.
- Mi clave de Stripe está en el código públicoStripe te da dos claves y solo una de ellas es un secreto. La publicable, que empieza por pk_, va en el navegador a propósito para que funcione el formulario de pago. La secreta, que empieza por sk_, permite cobrar, devolver dinero y leer los datos de tus clientes. Si la que está en tu código empieza por sk_, ese es el problema.
- Mi clave de OpenAI o de otro proveedor de IA está expuestaLa clave que usa tu app para hablar con OpenAI, Anthropic o el proveedor que sea está dentro del código que se descarga cualquiera que visite tu web. Esa clave no protege datos: autoriza gasto contra tu tarjeta.
- Mis source maps son públicos: se ve todo mi códigoAl construir tu app, el código se comprime hasta quedar ilegible. Los source maps son unos ficheros que deshacen esa compresión para poder depurar, y contienen tu código tal y como lo escribiste, con nombres y comentarios. Se han publicado junto a la app, así que cualquiera puede descargarlos y leerlo entero.
- La lógica de permisos deja entrar a quien no debeTu app decide quién puede ver o hacer cada cosa en el código que corre en el navegador del visitante. El problema es que ese código está en su ordenador, no en el tuyo: puede leerlo, cambiarlo y saltárselo. Ocultar un botón no impide la acción que había detrás.