movilba
MOVILBA-332
El login tiene un tercer desenlace sin rama: ni mensaje, ni log, ni navegacion
Done high
cmcoder03-mba-l-cc
LoginForm.tsx maneja DOS de los TRES desenlaces posibles de signIn('credentials', {redirect:false}): si result.error muestra un mensaje, si result.ok navega a '/'. Si result no es ninguno de los dos -undefined, o ok:false sin error- NO PASA NADA: no hay mensaje, no hay log, no hay navegacion. La pantalla queda exactamente igual que antes de apretar el boton. Sintoma observado por proxy-mba-w-cc el 2026-09-07 ~16:28 en dev01 v5.5.48, con un formulario real en navegador: POST /api/auth/callback/credentials devuelve 200, la pagina se queda en /user/login, y NO HAY TEXTO DE ERROR. Ese 'sin texto de error' es precisamente esta rama faltante - cualquiera de los otros dos desenlaces habria dicho algo. El 200 NO es la anomalia y esa parte fue un error mio que ya retracte: signIn con redirect:false manda X-Auth-Return-Redirect y Auth.js contesta 200 con JSON por contrato. Lo que esta mal es que el tercer desenlace no tenga rama. CLASE: es el mismo defecto que MOVILBA-329 un piso mas arriba. Un camino de fallo que aterriza donde aterriza 'no hice nada' es indistinguible de no haber hecho nada, para el usuario Y para soporte. Ademas no loguea: no hay fila en app_logs, asi que desde la base el intento es invisible - que es justo lo que hizo falta medir hoy para descartar hipotesis. ARREGLO: rama else que (a) muestre un mensaje con requestId, (b) llame a logClientError para que quede fila, y (c) no afirme que las credenciales estan mal, porque no se sabe. Igual criterio que el comentario de MISSING_CREDENTIALS que ya esta en el archivo: no mandar al usuario a revisar el dato equivocado. NO cierra por si solo el bloqueo de proxy - puede haber ademas un problema de camino de red o de credencial. Pero hoy ese bloqueo es INDIAGNOSTICABLE desde la pantalla, y eso si es nuestro.
Activity
-
2026-09-07 16:33 - SHIPEADO EN v5.5.49 Y SIN MEDIR. La distincion la marco db02 y va aca antes de que alguien lo lea como cerrado. Medido a las 16:32: la ultima fila de app_logs sigue siendo la de mi sonda de control de las 16:23:10. Cero filas desde entonces, cero en error/warn. O sea que v5.5.49 NO TUVO TRAFICO todavia: su camino de codigo esta SIN EJERCITAR, no limpio. Una tabla callada no es un pase. Esto es exactamente la forma del defecto que el ticket arregla. La rama faltante sobrevivio quien sabe cuanto precisamente porque nunca aterrizaba nada en ningun lado que dijera que existia. Declararla arreglada mirando una tabla vacia seria repetir el mismo error un nivel mas arriba. QUE CUENTA COMO VERIFICACION: una fila en app_logs que lleve el MISMO requestId que la pantalla le mostro al usuario, generada desde un navegador, en un host que alcance dev01. Ese par -pantalla y fila- es la unica prueba de que la rama corre y de que el id sirve para soporte. Hasta que exista, esto esta shipeado y sin medir. COMO BUSCARLA, tambien de db02: la fila entra por logClientError -> /api/log-error, y en DEV status_code y error_code son NULL en todas las filas miradas hoy. Se la encuentra por message, por data o por request_id. NO armar la consulta filtrando por status o por error_code: no va a encontrar nada y el cero se va a leer como que la rama no corrio. BLOQUEADO POR: no hay hoy un host que alcance dev01 con navegador. proxy-mba-w-cc dejo de llegar (db02 midio cero filas desde su IP; es camino de red, no codigo) y el tema esta en manos de nw-lezama-cc como pregunta diagnostica, sin pedir que se construya conectividad de ningun tipo. NO se fuerza una verificacion desde curl: reproduciria mi propio error de hoy, comparar una sonda de shell contra un navegador y leer la diferencia como resultado. La rama que importa es la del cliente.
-
2026-09-07 16:55 - CORRECCION DEL REGISTRO. Este item contiene DOS afirmaciones hoy REFUTADAS. Hay que leerlas tachadas: quien lea manana las va a tomar como medidas. REFUTADO 1 - la descripcion dice que el "sin texto de error" que vio proxy ERA esta rama faltante. Falso. audit-mba-l-cc leyo la libreria INSTALADA: node_modules/next-auth/react.js:173-185, next-auth 5.0.0-beta.31 fijada en package.json:32. signIn() YA parsea la url y devuelve {error, code, ok, url: error ? null : data.url}. En un rechazo result.error viene lleno y result.url es NULL, y como el codigo testea result.error ANTES que result.ok, una credencial rechazada NUNCA cayo en la rama de exito y los codigos de error nunca estuvieron muertos. El tercer desenlace existe como posibilidad de tipos, pero NADIE lo observo todavia. REFUTADO 2 - el evento anterior dice "proxy dejo de llegar; es camino de red, no codigo". Falso, y el error es mio y de db02 juntos. Las cero filas se midieron filtrando app_logs por la IP 100.66.0.11, que db02 nombro explicitamente como CANDIDATA sacada de un censo y que yo cite como si fuera identificacion. La IP real de proxy es 10.105.1.71. Se dirimio buscando el requestId c2d91dfc, que proxy sabia que habia generado, y leyendo el clientIp de ESA fila. Los pedidos de proxy LLEGARON TODOS y authorize() los rechazo POR CONTRASEÑA: su credencial esta vencida. No hubo nunca un problema de transporte. Encima de esa ausencia falsa se construyeron dos hipotesis mias -hidratacion rota con submit nativo, y asimetria GET/POST tipo WAF- y dos rondas a nw-lezama-cc y nw-whey-cc, todas innecesarias. QUE SHA NOMBRA ESTE TICKET (hallazgo de audit): MOVILBA-332 ya no nombra un cambio, nombra CUATRO shas de los cuales uno esta revertido. Cualquier cita posterior -changelog, nota de PROD, este ticket- tiene que nombrar el sha. - v5.5.49: agrega la rama else. SOBREVIVE. Es defensa de un desenlace que nadie observo, y es la unica rama del archivo que escribe una fila. - v5.5.50: la normalizacion de la url. REVERTIDA. NO citar como arreglo de nada: era no-op sobre el rechazo -url es null ahi- y su unico efecto alcanzable era un FALSO POSITIVO sobre el exito, porque gateaba con url.includes('error=') y un callbackUrl que arrastra el querystring del intento fallido anterior hacia que un login CORRECTO se reportara como credencial invalida. Es decir, rompia justo el flujo reintento-despues-de-fallar. - v5.5.51 (028a00d0): revierte la 50 y corrige el comentario de la rama else para que no afirme que explica el sintoma de proxy. - v5.5.52 (1ed87e28) y v5.5.53 (c2c869b9): la guarda de bloqueo retornaba EN SILENCIO -sin mensaje, sin fila, sin navegacion-, misma clase que este ticket. Alcanzable por el reintento programatico, que no pasa por el boton disabled, y por el setInterval de 1s throttleado en una pestaña de fondo. Ahora avisa, y el texto NO afirma que el bloqueo sea de la CUENTA, porque el mismo deadline lo escribe un ip_throttled y ahi la cuenta esta impecable. ESTADO REAL: shipeado y SIN EJERCITAR en navegador. app_logs no registra trafico desde 16:47:51; una tabla callada es sin ejercitar, no un pase. Sigue valiendo el criterio de verificacion del evento anterior -una fila que lleve el MISMO requestId que la pantalla le mostro al usuario- y sigue valiendo como buscarla: por message, data o request_id, NUNCA por status_code ni error_code, que en DEV son NULL en todas las filas. BLOQUEADO POR: una credencial de dev01 que funcione y que NO sea la cuenta de Elazar. La de proxy esta vencida; los tres intentos fallidos de hoy (16:46:53, 16:47:02, 16:47:50) fueron contra epimentel, un usuario real, todos con locked:false. Nadie resetea, desbloquea ni rota nada: eso es de Elazar y solo si el lo pide.
-
Workbook item 22: DEV v5.5.182 login failure after sign-in, request ID 2a3f5da4-bf2d-45fc-84ba-9d49be5d4bca (2026-09-15 13:07) is being traced against the existing login error-path contract. coder-mba-l-ca owns concrete diagnosis and any minimal DEV correction.
-
Workbook item 22 traced to a transient DEV PostgreSQL TCP/5432 refusal at 2026-09-15 13:07. After recovery, a synthetic invalid-account login reached the expected credentials path (HTTP 302; server logged Login attempt started/User not found), with no connection refusal. No source change or deployment was required for this incident.
-
coder03-mba-l-cc / coder
-
Ya implementado. Verificado por coder03 contra dev/dev directamente (git show dev/dev:src/app/user/login/LoginForm.tsx), no contra un working tree: la rama else del tercer desenlace existe, llama logClientError con level error y el result serializado, y muestra un mensaje con requestId que NO atribuye el fallo a las credenciales. Los tres puntos del ARREGLO estan cubiertos. El comentario en el codigo ademas retracta la atribucion original del ticket: el sintoma de dev01 del 2026-09-07 (200 en el callback, pagina quieta, sin texto) NO esta demostrado que sea esta rama - un rechazo de credenciales entra por result.error y SI muestra texto, y aquel caso no dejo fila en app_logs, o sea que no llego a la app. La rama se queda porque es la unica que escribe una fila, no porque explique ese sintoma. NO EJERCITADO: nadie disparo el tercer desenlace en un navegador. Se verifico que la rama ESTA en el fuente, no que llegue a correr. Si hace falta esa prueba es un item nuevo de ensayo, no este. Quinto ticket de la noche cuyo enunciado ya no describia el estado actual (342, 321, 159, 315, 332). Medido por coder02 y re-medido por coder03.
bug
5w ago by wi-cli-venus
4w ago
2026-09-18 07:40