Solución de problemas
Casi todo lo que falla en Autoreel falla en silencio: sin error, con el despliegue en verde y el código correcto. Esta página va del síntoma a la causa sin pasar por adivinar.
Síntoma y causa
| Síntoma | Casi siempre es |
|---|---|
| El diagnóstico no conecta a la base | Falta POSTGRES_URL en .env.local y la conexión cae al valor por defecto |
| Creo videos y la biblioteca sigue vacía | Falta AUTOREEL_OWNER_ID, o no es el identificador de la cuenta con la que entras |
| El video queda listo pero la web dice que no está disponible | No se subió al almacenamiento: falta SUPABASE_SERVICE_ROLE_KEY |
| El render se queda esperando | La web no responde en AUTOREEL_BASE_URL |
| Videos atascados en generación | Un worker que murió a mitad. Se re-encolan solos cuando arranca el siguiente |
| El texto se sale de su caja en el video | No debería: lo ataja el validador. Si pasa, la estimación de ancho se quedó corta para esa fuente |
| Una página nueva contesta 404 en producción | Mirar los patrones de .vercelignore: sin barra inicial excluyen esa carpeta en cualquier nivel |
Los tres fallos silenciosos
El dueño que falta
Es el peor porque todo lo demás funciona: el video se genera, el archivo existe y la cola avanza. Simplemente no aparece, porque cada consulta de la web filtra por dueño y esas filas no tienen ninguno. El diagnóstico lo avisa y lista los identificadores disponibles.
El archivo que no se subió
El worker marca el video como listo solo después de subirlo, así que esto no debería pasar. Cuando pasa, es que la subida falló y quedó avisado en el registro del worker: el archivo está en el disco de la máquina que renderizó y no donde la web lo busca.
La carpeta que el despliegue se comió
Los archivos de exclusión usan la sintaxis de .gitignore, donde un patrón sin barra inicial coincide con una carpeta de ese nombre en cualquier nivel. Una línea puesta para no subir la documentación del repositorio puede llevarse por delante una página de la aplicación, y el despliegue termina en verde igual.
Cómo se detecta
Empezar por el diagnóstico
npm run doctorRevisa el runtime, las piezas de medios, la base de datos, las cuentas y la web, y contesta una por una. Antes de sospechar del código, conviene leer lo que contesta: casi siempre el problema está ahí, escrito.
Si el diagnóstico está en verde y el síntoma sigue, la siguiente parada es la arquitectura: saber qué mitad del sistema es responsable de lo que falla ahorra la mitad de la búsqueda.