requestId mostrado al usuario no existe en app_logs (5514405e vs 06d9449a real)

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  CAUSA RAIZ LOCALIZADA (coder-mba-l-cc, 2026-08-20, lectura de codigo - no medido en runtime). No faltan filas en app_logs: la misma falla de login queda con DOS requestId distintos. src/lib/auth.ts:140, dentro de authorize(), hace `const requestId = generateUUID()` pelado - ese es el id que va a la pantalla y a login_attempts. logger.ts, en cambio, prefiere el del contexto HTTP (`requestId = ctx.requestId || passedRequestId`), asi que app_logs guarda el del request. Por eso joinear login_attempts con app_logs por request_id da CERO SIEMPRE, por construccion, y hoy se rastrea por timestamp. FIX: el patron correcto ya existe en el MISMO archivo, auth.ts:26 -> `requestId: ctx.requestId ?? generateUUID()`. La 140 es la unica linea que no lo adopto. Cambio de una linea. NO TOCAR el `|| passedRequestId` de logger.ts: el agrupamiento por request HTTP es deliberado y tiene otros callers. NO awaitear los logs antes del throw: era una hipotesis de db-mba-l-cc, retirada formalmente - refutada por su propia consulta, que buscaba ILIKE '%Missing credentials%' cuando el string real es 'Missing email or password'. RIESGO LATENTE, verificado hoy y hoy inocuo: logger.ts:132 (rama nueva de 3 args) hace `ctx.requestId || crypto.randomUUID()`, o sea se inventa uno propio sin passedRequestId que lo salve. Hoy no desalinea nada porque TODAS las llamadas de auth.ts usan la firma vieja de 5 args. Si alguien migra esas llamadas a la firma nueva, el defecto vuelve por ese camino.
• wi-cli-venus assigned · 2026-08-20
  coder-mba-l-cc / coder
• wi-cli-venus commented · 2026-08-20
  db-mba-l-cc 2026-08-20: causa raiz CORREGIDA. No se pierde ningun log: app_logs tiene las 26 filas de 'Missing email or password' (2026-02-24 a 2026-08-19 23:45:28). El bug es que la misma falla lleva DOS requestId - logger.ts (rama de firma vieja) hace requestId = ctx.requestId || passedRequestId, o sea DESCARTA el que se le pasa; authorize() (auth.ts:140) genera el suyo con generateUUID() pelado y lo escribe en login_attempts + en el code del error que ve el usuario. Verificado 6 de 6 eventos: id de pantalla distinto del de app_logs, mismo milisegundo. FIX localizado por coder-mba-l-cc: auth.ts:140 debe adoptar el patron que ya existe en auth.ts:26 (ctx.requestId ?? generateUUID()); NO tocar el || passedRequestId de logger.ts ni awaitear el log (no falta ningun log). RIESGO LATENTE a anotar en el fix: la rama de firma NUEVA de logger.ts (~linea 132) hace ctx.requestId || crypto.randomUUID() y ahi el fallback inventa un id sin passedRequestId que lo salve; hoy no aplica porque las 20 llamadas de auth.ts usan firma vieja (medido por coder02-mba-l-cc), pero se desalinea sola si alguien las migra. WORKAROUND DE SOPORTE VIGENTE HOY sin deploy: buscar el id reportado en login_attempts (email='missing-email' cuando faltaron credenciales), sacar created_at, y con ese timestamp ir a app_logs.
• wi-cli-venus commented · 2026-08-20
  Contexto de causa raiz, medido por coder02-mba-l-cc (2026-08-19/20), para no reinvestigar: MECANICA: src/lib/auth.ts:140 dentro de authorize() hace generateUUID() pelado; ese uuid va a login_attempts Y al code del error que ve el usuario. logger.ts (rama de firma vieja) hace 'requestId = ctx.requestId || passedRequestId; // Prefer context!' y DESCARTA el pasado, persistiendo el del contexto HTTP. Dos ids para la misma falla, 6 de 6 casos verificados en prod. FIX ELEGIDO: NO tocar el '|| passedRequestId' del logger - ese 'Prefer context' es deliberado, agrupa los logs de un mismo request HTTP y tiene otros callers. El patron correcto ya existe en el MISMO archivo, auth.ts:26: 'requestId: ctx.requestId ?? generateUUID()'. La 140 es la unica que no lo adopto. TRAMPA A DEJAR DOCUMENTADA AL ARREGLAR (la levanto db-mba-l-cc, la verifique yo): la rama NUEVA de logger.ts (~linea 132) hace 'ctx.requestId || crypto.randomUUID()' - ahi el fallback inventa un id propio y no hay passedRequestId que lo salve, o sea vuelve a desalinear. Hoy NO aplica: parsee las 20 llamadas a log() de auth.ts contando argumentos de nivel superior y las 20 son firma vieja de 5 args, cero con firma nueva. Pero vale HOY y por accidente: la primera llamada de auth escrita con firma nueva rompe la alineacion en silencio. Conviene dejarlo escrito en el codigo. Las 26 filas historicas de app_logs quedan huerfanas igual; el fix sirve de ahi en mas. WORKAROUND DE SOPORTE, sirve YA sin deploy: buscar el id reportado en login_attempts, tomar created_at, ir a app_logs por ese timestamp. Probado: 5514405e en login_attempts 23:45:28.970 -> app_logs 06d9449a a .969864 y .983156.
• wi-cli-venus statusChanged · 2026-08-20
  Fix shipped to dev: authorize() now reuses ctx.requestId (src/lib/auth.ts). Awaits Elazar GO for prod deploy; the 26 historical rows stay orphaned by design.
• wi-cli-venus completed · 2026-08-20
  Shipped to PROD as v5.3.215 (main cd2449e2). /srv/movilba-web serves 5.3.215 with authorize() reusing ctx.requestId. Also pushed to gcaba/develop, Tekton EL 202, POD rebuilding. The 26 historical rows stay orphaned by design.