Architect — F-054

Diagnóstico

El backend (dist/infrastructure/http/server.js) muere sin dejar trazas de error en el log: el último msg es un request completed 200, y luego silencio.
Cuando el backend está caído, los proxies devuelven:
- GET/POST /api/auth/login en admin (3004) → 502 (catch del proxy en [...path]/route.ts)
- POST /api/auth/login en frontend (3003) → 500 (catch en src/app/api/auth/login/route.ts)
El frontend hardcodea http://127.0.0.1:3000 mientras el admin usa process.env.NEXT_PUBLIC_API_URL ?? 'http://127.0.0.1:3000'. Inconsistencia menor pero no causa de este ticket.

Causa raíz probable

El proceso fue terminado por SIGTERM/SIGKILL — posiblemente cuando el shell que lo lanzó (nohup ... &) fue reaped por el harness de Pi. nohup evita SIGHUP pero no SIGTERM/SIGKILL que pueda llegar desde el agente.

Diseño

Watchdog en monolith.sh: nueva función ensure_alive() que verifica si el PID en <service>.pid sigue vivo (vía kill -0) y, si no, lo relanza con spawn_service. Se invoca al inicio de status y se ofrece como comando explícito monolith.sh prod watch.
Frontend /api/auth/login: usar process.env.NEXT_PUBLIC_API_URL ?? 'http://127.0.0.1:3000' igual que el admin. Cambio defensivo (no causa el bug pero evita uno futuro si se despliega el frontend en otro host).
Diagnóstico de la muerte del backend: añadir un handler de uncaughtException y unhandledRejection en server.ts que loguee el error antes de morir. No previene la muerte pero ayuda a diagnosticarla la próxima vez.
monolith.sh prod status mejorado: ahora también dispara ensure_alive antes de imprimir la tabla, así el operador ve servicios vivos sin tener que reiniciar manualmente.

Alternativas descartadas

systemd / launchd: fuera del scope del proyecto (no se asume init del sistema).
PM2 / forever: añadiría una dependencia runtime al proyecto.

Acceptance

Si el backend muere, ./project/scripts/monolith.sh prod status lo detecta y lo relanza automáticamente.
frontend/src/app/api/auth/login/route.ts lee NEXT_PUBLIC_API_URL con fallback a 127.0.0.1:3000.
server.ts loguea uncaughtException y unhandledRejection antes de morir.
Smoke: matar backend manualmente (kill <pid>), esperar 5s, correr monolith.sh status, ver backend running de nuevo.

Riesgos

El watchdog añade latencia al status (1 ciclo de kill -0 por servicio, <1ms).
Ningún cambio en runtime de los handlers API; solo el catch ya existente sigue devolviendo 500/502 cuando el backend está realmente caído.

2.6 KiB Raw Blame History