/api/health no probaba la base en el camino anonimo, que es el unico que lee el gate de deploy
SHIPEADO 2026-09-29, v5.6.106, commit 6c77adf2, src/app/api/health/route.ts. El numero se uso en el commit antes de existir el item, asi que el item se ajusta al commit y no al reves; el hallazgo del gate de prod que motivo la confusion vive en MOVILBA-614. DEFECTO. La sonda a la base estaba detras del chequeo de sesion, asi que la respuesta ANONIMA - la unica que lee mba-deploy-dev.sh - era un literal JSON que no podia fallar. Habia un tercer camino igual de ciego: cookie presente pero invalida devolvia {status:'ok'} pelado, alcanzable por cualquiera que mande una cookie basura. Medido el mismo dia, con causa real y no simulada: ASI roto la password de movilba_user@10.9.10.54 (ticket RE-1696847) y /api/health siguio contestando 200 mientras toda ruta con base contestaba 500 DATABASE_ERROR. Un deploy en esa ventana se habria declarado sano. ARREGLO. La sonda corre en los tres caminos y la respuesta lleva 503 cuando la base no responde. El CODIGO es lo que la convierte en gate: el script lee el body solo para el serviceId y decide con curl -fsS, que falla ante cualquier >=400 - un 200 con 'degraded' en el cuerpo habria pasado igual. El resultado se cachea 5s y los llamadores concurrentes comparten la consulta en vuelo, asi que N pedidos anonimos cuestan a lo sumo un select 1 por ventana: se conserva la propiedad anti-amplificacion de MOBAAPI-677, que es la razon por la que la sonda estaba escondida al principio. CONTROL FORZADO, no inferido: iptables REJECT a 10.9.10.54:5432 -> 503 degraded; regla quitada -> 200 ok; ninguna regla quedo puesta. Mas la observacion previa de 200-con-base-caida, que es el control negativo contra el comportamiento viejo. Gates: typecheck y pnpm build corridos a mano antes del push, porque ningun camino de ship construye (MOVILBA-612).
Activity
-
/api/health no probaba la base en el camino anonimo, que es el unico que lee el gate de deploy
-
was: Levantado por audit-mba-l-cc el 2026-09-29 revisando MOVILBA-613. mba-deploy-dev.sh corre un gate de salud contra DEV_HEALTH_URL, y desde MOVILBA-613 ese gate ya puede fallar de verdad: /api/health devuelve 503 cuando la base no responde. mba-deploy-prod.sh NO corre ningun gate de salud - pushea a main, imprime 'production is building' y sale 0. Nadie mira si prod levanto. La asimetria va justo al reves de la prioridad declarada: el entorno que NO es el foco tiene el control y el que SI lo es no lo tiene. Un prod que no arranca, o que arranca sin base, termina con exit 0 y un mensaje de exito. Hermano de MOVILBA-612 (ningun camino de ship corre next build). Los dos son gates ausentes en el camino a prod. Condicion de aceptacion, y tiene que verse FALLAR contra el comportamiento previo: con prod apuntado a una base inalcanzable, mba-deploy-prod.sh sale distinto de 0 y nombra la causa. Un verde contra un prod sano no prueba nada - es exactamente el modo de falla que MOVILBA-613 acaba de cerrar en dev.
-
audit pass: diff exacto de src/app/api/health/route.ts en 6c77adf2: los tres caminos de GET, la sonda compartida con TTL y single-flight, y los codigos 200/503. Corridos build, typecheck y test:source 38/38 sobre HEAD
payload
{"scope":"diff exacto de src/app/api/health/route.ts en 6c77adf2: los tres caminos de GET, la sonda compartida con TTL y single-flight, y los codigos 200/503. Corridos build, typecheck y test:source 38/38 sobre HEAD","outcome":"pass","evidence":"audit-mba-l-cc 2026-09-29 16:08 ART. Sin bug. Traza del 503 por api-client.ts: cae en isRetryableStatus, reintenta y envuelve en ConnectionError al agotarse. Un consumidor no declarado por el carril cambia de conducta y a favor: LoginForm.testConnectivity ahora reporta connected:false en una caida real, antes reportaba siempre connected:true porque health siempre daba 200. mba-deploy-pod.sh solo imprime la linea de curl, no la ejecuta. mba-deploy-prod.sh no tiene gate de salud y no se ve afectado - eso quedo como MOVILBA-614. TTL de 5s sin objecion: ningun prober depende de frescura sub-5s","reportRef":null} -
Shipeado en v5.6.106 (6c77adf2) y promovido a main en v5.6.107 (912e5264). PASS de audit post-hoc. Prod sirviendo serviceId 15570 = patch 107.