[backend] /health da verde con el pipeline inutilizable: el fallo del warmup se traga

[sergi-torres]

El defecto

backend/app/main.py se traga el fallo del warmup, así que /health devuelve verde aunque el pipeline sea inutilizable. El healthcheck no comprueba en ningún momento que la generación pueda funcionar: solo que el proceso esté vivo y respondiendo HTTP.

Esta es la razón por la que el backend se desplegó roto y el despliegue parecía correcto. Con el modelo en_core_web_lg ausente, Railway veía un healthcheck en verde mientras cada llamada a /api/generate devolvía un 500.

Descubierto el 2026-07-28 mientras se ejecutaban las correcciones de WO-02 / #83. Se reporta y se para, según la regla del protocolo de despacho.

Por qué importa más de lo que parece

Un healthcheck que no puede fallar no es un healthcheck, es un adorno. Su función es exactamente la contraria a la que cumple hoy: debe ponerse rojo cuando el servicio no puede hacer su trabajo, para que Railway no promocione un despliegue inservible y para que el fallo se vea en el panel en vez de en la demo.

Nótese que #83 arregla la causa concreta que se manifestó esta vez (el modelo ausente), pero no arregla el mecanismo. El siguiente fallo de arranque que ocurra por otro motivo se comportará igual: verde por fuera, 500 por dentro.

Qué habría que hacer

• Que el fallo del warmup deje de tragarse silenciosamente: como mínimo debe quedar registrado con nivel de error.
• Que /health refleje el estado real del pipeline. Conviene distinguir liveness (el proceso responde) de readiness (el pipeline puede generar): son dos preguntas distintas y Railway se apoya en la segunda para decidir si promociona el despliegue.
• Añadir una prueba que demuestre que el healthcheck se pone rojo cuando el pipeline no está disponible. Sin esa prueba, el arreglo no es verificable: un healthcheck que siempre da verde y uno correcto son indistinguibles mientras todo va bien. Esto es un control positivo, y es el mismo patrón que se le exigió al verificador de [backend] WO-17 — Test flaky en la verificación del Passport: la firma "manipulada" a veces sigue siendo válida #99.

Relación con otras órdenes

• [infra] WO-02 — Instalar las dependencias de ai_pipeline en la imagen de Railway #83 / WO-02 arregla el síntoma de esta vez y sube healthcheckTimeout a 300. No toca este mecanismo.
• Ver también la issue hermana sobre la descarga de 418 MB en cada arranque en frío, que es el otro motivo por el que el arranque es frágil.

Prioridad

Alta pese a no ser un criterio del Definition of Done. Con la entrega el 31-jul y una demo en vivo por delante, el coste de este defecto no es el fallo en sí: es enterarse tarde. Hoy no existe ninguna señal automática que distinga un backend sano de uno que devuelve 500 en todas las generaciones.