Un error nacido en el cliente muestra un requestId que no existe en app_logs: log() no persiste en el navegador y nadie llamaba a /api/log-error
TRES huecos distintos, todos con el mismo sintoma: un UUID en el modal que no resuelve contra ninguna fila. 1. EL PRINCIPAL, y explica el caso de Elazar: log() es isomorfico y su INSERT a app_logs esta guardado por typeof window === 'undefined' (logger.ts:190). En el navegador escribe a la CONSOLA y nada mas. logAndShowError llama a log(), no a logClientError(), asi que TODO error nacido en el cliente mostraba un requestId inexistente. /api/log-error ya existia y estaba endurecido (MOBAAPI-641: rate limit por IP, tope de body, userId de la sesion del servidor). Solo faltaba llamarlo. Arreglado en logAndShowError, con el MISMO requestId que ve el usuario. 2. La deteccion de bundle desactualizado de MOVILBA-247 estaba cableada SOLO a window.onunhandledrejection. Un componente que atrapa su propio error -lo correcto, y lo que hacen las 23 pantallas- impide que el rechazo sea unhandled, asi que la recuperacion NUNCA corria donde el manejo de errores estaba mejor hecho. El texto exacto que vio Elazar, 'Error inesperado al crear el colectivo', es el catch del cliente en page.tsx:380, e isConnectionError dio false. Arreglado en createErrorInfo. 3. crearColectivo devolvia las dos salidas de autorizacion SIN requestId y sin loguear. Un rechazo que el servidor no registra es invisible para soporte e indistinguible de un crash. Arreglado. Aparte, MOVILBA-150: app_logs.status_code y error_code eran NULL en TODAS las filas porque el logger los lee en el nivel superior del data y todos los log() de error los mandaban anidados en data.error.code. Arreglado moviendo el log a createErrorResponse, que ademas cubre los 44 archivos de ruta que lo llaman directo y no logueaban NADA.
Activity
-
Shipeado en 5b87f900 (v5.5.43) y 3a853511 (v5.5.44), los dos verificados sirviendo por serviceId. Las tres causas del sintoma que reporto Elazar: log() no persiste en el navegador y logAndShowError no llamaba a logClientError; la recuperacion de bundle desactualizado de MOVILBA-247 estaba cableada solo a onunhandledrejection y por eso NO corria en las 23 pantallas que atrapan su propio error; y las dos salidas de autorizacion de crearColectivo no devolvian requestId ni logueaban. Y un cuarto, encontrado por audit sobre mi propio arreglo y REPRODUCIDO contra el build corriendo antes de arreglarlo: /api/log-error insertaba el requestId del payload sin validar en una columna de tipo uuid, asi que un id no-UUID reventaba el INSERT, el catch devolvia 500 y el error del cliente se DESCARTABA EN SILENCIO - en el endpoint cuyo trabajo entero es evitar eso. 5.5.43: POST con 'no-soy-un-uuid' -> 500. 5.5.44: -> 200, con el string rechazado preservado en data.untrustedClaimedRequestId. Alcance real: nuestra UI no lo disparaba, asi que el caso de Elazar no estaba afectado; lo alcanzaba un llamador publico y cualquier call site futuro con un id que no fuera UUID. LO QUE NO CAMBIA: las 23 pantallas reciben el MENSAJE de bundle desactualizado, no la RECUPERACION - manejarBundleDesactualizado() sigue solo en onunhandledrejection, a proposito, porque un error atrapado tiene un componente que puede estar reteniendo lo que el usuario escribio. NO CUBIERTO: el error original de Elazar contra el build actual, una sesion viva con permisos denegados, la rama de rate limit, y el volumen de 4xx en uso real.