Server actions devuelven error.message crudo: divulgacion de esquema en 27 paths de src/actions/
Medido por coder03 2026-09-07, nada arreglado. SINTOMA: el modal renderiza "Failed query: update vehiculos set dominio..." (proxy, v5.5.28, req f9fc45a3-b857-49de-bfd7-195102e3ff90). El DOM es UNA superficie, no la fuga. 1. ENTRADA: el catch general de la capa de ACCION, no un call site. src/actions/vehiculos.ts:390 devuelve { success:false, error: error.message }. 27 returns asi en 9 archivos de src/actions/. Convencion MIXTA: la mayoria de los catches de esos mismos archivos devuelven un string FIJO. 2. SALE DEL SERVIDOR: el texto crudo viaja en el payload de la accion, o sea en el body HTTP, sin modal y sin JS. Y el log() de arriba YA manda serializeErrorForLog(error) a app_logs: devolverlo no aporta valor diagnostico y solo paga la divulgacion. Eso cierra la objecion "lo necesitamos para debuggear". 3. NO AUTENTICADO, premisa corregida: el login NO filtra, LoginForm.tsx:110-140 mapea CODIGOS a mensajes curados y ya es la convencion destino. De 20 rutas API con el patron, la unica sin auth es api/auth/federated-logout/route.ts:65 y ahi es un log, no un body. LA EXPOSICION REAL: el guard de auth esta ADENTRO del try, asi que si auth() o hasPermission() TIRAN (DB caida, sesion no decodificable) ese mismo catch devuelve el mensaje crudo a alguien que nunca se autentico. La llamada normal sin sesion devuelve el fijo No autorizado: lo que filtra es el MODO DE FALLA. FORMA DESTINO, ya existe en el repo, no inventar una tercera: mensaje humano accionable + requestId en la UI, error crudo SOLO a app_logs correlacionado por ese id. DOS BARATAS: ErrorModal.tsx:119 y :146-150 concatenan titulo y mensaje SIN separador; y el banner pide mandar a soporte un texto que hoy es un fragmento de query - primero el contenido, despues la copy es verdadera.
Activity
-
Fixed v5.5.236 85a31f3d. El '27 paths' del titulo no sobrevivio a la re-medicion: de los 28 sitios con error.message crudo en src/actions/*.ts (17 archivos no-test, 10 con hits), 27 estaban DENTRO de un log() - server-side, correcto, y en su mayoria ya arreglados por el barrido del 09-07 (grupos 1a/1b/2 + ApiException/mensajeParaUsuario). Verificado sitio por sitio por coder03, no por muestreo: asociaciones 9, choferes 8, instalaciones 3, lineas 2, validadoras 2, entidades 1, personas 1, api-docs 1, vehiculo-match 1, todos en payload de log(). Una sola fuga real al cliente sobrevivia: src/actions/reportes.ts getLiquidacionMensual, sin log() y sin requestId, devolvia error.message crudo. Arreglado con el mismo patron de entidades.ts/personas.ts: log() con requestId server-side + mensajeParaUsuario(error, fallback) al cliente + requestId en el Result. El throw de abajo (afirmarCatalogoTramiteAlta, liquidacion.ts) es un Error plano, no ApiException, asi que colapsa al fallback generico por diseno y el detalle queda solo en app_logs. Sin cambio de UI: src/app/reportes/liquidacion/page.tsx ya llamaba requestIdDelServidor(result), solo que nunca recibia el campo. Trabajo de coder02-mba-l-ca, medicion re-verificada y landeada por coder03.
-
coder02-mba-l-ca: fixed the single client-facing leak (src/actions/reportes.ts getLiquidacionMensual), classified all 27/28 grep hits by enclosing construct (log() vs return), 27 already server-only from prior sweep. tsc clean. Handed diff to coder03-mba-l-cc via hub; coder03 landed as 85a31f3d/v5.5.236.