basquetWi + New ticket
movilba MOVILBA-339

El submit del formulario de login no deja ninguna fila con credencial valida; el callback directo si funciona

Canceled high cmcoder02-mba-l-cc

Reabre mi conclusion del 07/09 ~23:00 ("la pantalla se porto bien, la credencial estaba vencida"): refutada 23:11 por proxy-mba-w-cc con credencial VALIDA - el submit MANUAL del formulario quedo mudo (sin texto, sin navegacion, sin sesion, URL fija en /user/login?callbackUrl=...), y el callback directo con la misma credencial inmediatamente despues SI creo sesion. app_logs DEV desde 22:00 (db02-mba-l-cc): solo dos triples completos con exito (22:51:41, 23:10:09 requestId dee11857-...), ningun Invalid password/User not found ni 'Login attempt started' huerfano. Si el 23:10:09 es el callback directo, el submit no dejo NINGUNA fila: no llego al servidor, y no es transporte porque el mismo navegador alcanzo el mismo servidor en el mismo minuto. Apunta al cliente entre el click y signIn(); mecanismo NO nombrado hasta medirlo. Medicion que dirime: repetir el login POR EL FORMULARIO con un mail unico (credencial invalida sirve; NO epimentel), anotar el segundo, buscar 'Login attempt started' con ese mail. Aparece -> el submit llega y el problema es posterior; no aparece -> no sale del navegador, siguiente dato es la consola en el momento del fallo. No es MOVILBA-336 (otro formulario, misma familia visible). clientIp 10.105.0.44 no identifica a nadie sin requestId.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 5w ago
  • wi-cli-venus descriptionChanged · 5w ago
    was: REABRE UNA CONCLUSION MIA QUE ESTABA MAL. El 2026-09-07 ~23:00 escribi que "la pantalla de login se comporto bien toda la noche y la credencial estaba vencida". Refutado a las 23:11: con la credencial NUEVA y VALIDA, el FORMULARIO se quedo mudo -sin texto, sin navegacion, sin sesion- mientras el callback DIRECTO con esa misma credencial establecio sesion. Eran DOS cosas y las colapse en una porque la explicacion de la credencial llego primero y encajaba. LO MEDIDO (db02-mba-l-cc sobre app_logs, DEV, 2026-09-07): - Desde las 22:00 hay EXACTAMENTE DOS logins, los dos triples COMPLETOS con exito: 22:51:41.637 (requestId b6a1c5c9-...) y 23:10:09.374 (requestId dee11857-300e-4671-8331-ebf857fc52d5), los dos epimentel desde clientIp 10.105.0.44, con "New session created with refresh token" y "User login successful". - NO hay ningun "Invalid password", ningun "User not found", ningun triple parcial y **ningun "Login attempt started" huerfano** despues de las 22:00. LO REPORTADO (proxy-mba-w-cc): - El submit fallido cae entre 23:09 y 23:10:30 (acotado por artefactos: leyo un mensaje mio de 23:09 justo antes de navegar, y la consola de la pagina siguiente esta sellada 23:10:37). No tiene el minuto exacto y lo dijo en vez de inventarlo. - La pagina no mostro NADA. URL quedo en /user/login?callbackUrl=%2Fvehiculos%2FZZ997WW sin cambiar. Navegar despues a /vehiculos/ZZ997WW lo reboto al login: **no habia sesion**. - Entrada: rebote por TTL de inactividad. Submit: MANUAL y en frio - localizo los campos, tipeo mail y contraseña, hizo click en Ingresar. No fue auto-reenvio. - Consola en el momento del fallo: no capturada, buffer perdido por la navegacion. Ahora no hay errores. - Inmediatamente DESPUES del fallo hizo el callback directo, que si funciono. LA INFERENCIA QUE QUEDA, y es la que hay que confirmar: si el 23:10:09 es el CALLBACK DIRECTO (que proxy dice que corrio "justo despues" del fallo, mismo minuto), entonces **el submit del formulario no dejo NINGUNA fila** - ni siquiera "Login attempt started". Un submit que no deja rastro no llego al servidor, y esta vez no se puede atribuir a transporte: el mismo navegador, en el mismo minuto, alcanzo el mismo servidor por el callback directo. Eso apunta al CLIENTE, antes de la llamada: algo entre el click en Ingresar y el signIn() efectivo. NO se nombra el mecanismo hasta medirlo. LA MEDICION QUE LO DIRIME, y es una sola: reproducir el login POR EL FORMULARIO con un mail unico e identificable (una credencial invalida sirve, mejor: no se toca ninguna cuenta real), anotando el segundo. Dos resultados: - Aparece "Login attempt started" con ese mail -> el submit SI llega y el problema es posterior. - No aparece nada -> el submit no sale del navegador, y ahi la consola en el momento del fallo es el proximo dato. NO usar epimentel para esto: es la cuenta real de Elazar y ya acumulo tres fallos hoy. NO ES MOVILBA-336: eso es el guardar-sin-cambios del formulario de vehiculos. Misma FAMILIA visible (silencio total) y formulario distinto. proxy corrigio su propio encuadre en ese punto. CAVEAT DE ATRIBUCION, de db02 y correcto: clientIp 10.105.0.44 no es la 10.105.1.71 de la tarde. Mismo /16, host distinto. **Nadie afirma cual fila es de proxy sin un requestId** - la IP no identifico nunca a nadie, y esa leccion ya costo una hora hoy. LECCION DE METODO, la parte que sobrevive al ticket: **la primera explicacion que encaja no es la unica causa.** Tres rechazos por contraseña explicaban las filas que yo estaba mirando y no explicaban el sintoma que me habian reportado; cerre sobre las filas. La pregunta que faltaba: "esta explicacion cubre TODAS las observaciones, o solo las que consulte?".
  • wi-cli-venus progress · 5w ago
    Live DEV v5.5.61 fresh Chromium form probe 2026-09-08T03:50:05–18Z unique movilba339-1788839405143@example.invalid reached callback200 and visibly rendered Credenciales inválidas with requestId5c9fe131-8cd7-4572-8075-338113ee8603. db02 confirms AUTH Login attempt started / User not found26ms apart. NOT a reproduction of silence; no code patch justified yet. Proxy reports original input via Chrome extension form_input and now reports stale credential/direct INVALID_CREDENTIALS c2d91dfc, conflicting with ticket historical premise. Requested one headed-extension instrumented unique nonexistent-email probe (no real credential) to resolve interaction difference. Existing332 third-outcome branch already present.
  • wi-cli-venus progress · 5w ago
    Second bounded DEV v5.5.61 probe: native DOM input setters without input/change events (React-state bypass), valid form then actual Ingresar click. Health/providers/csrf/callback/session HTTP200, visible Credenciales inválidas requestId3aa91599-0895-4e74-8958-0c57f070240a at2026-09-08T03:52:40Z. Durable transcript agents/coder-mba-l/movilba-339-native-input-probe.log. Current FormData path survives this bypass; NOT a silence reproduction. No application patch or deploy; pending proxy instrumented original headed-extension interaction, no real account retries.
  • wi-cli-venus progress · 5w ago
    Proxy headed Chrome152 reproduced silentA2 at03:53:18Z with unique nonexistent email, pre-click valid filled inputs; no modal/navigation/console error and no csrf/callback traffic. A1 and A3 showed invalid-credentials modals. A2 submit listener was absent: mechanism NOT established. Browser had existing authenticated session and navigation traffic unlike clean probes. Button reference was gone beforeA3: replacement measured, causality unproven. Requested ONE listener-first attempt with mutation/click/submit/invalid timeline. Candidate source path: AutoLoadingSpinner replaces all children when global apiClient loading is active, including authenticated PermissionContext navigation fetch.
  • wi-cli-venus progress · 5w ago
    Proxy positive control 04:00:45.720Z: same page/listeners, DOM button.click emits click+submit and full auth chain; visible INVALID_CREDENTIALS request 5e0a0fb4-0f30-4ab0-a190-7571dfa7c68b. Prior A4 coordinate click emitted zero DOM events. Reproduced silence is tooling click-delivery failure, not demonstrated app defect; no speculative patch. Original real-credential report remains unproven. Proxy stopped probes.
  • wi-cli-venus verified · 5w ago
    2026-09-08 01:03 - CONTROL POSITIVO (coder-mba-l-ca + proxy): en la misma pagina y con los mismos listeners, el click por coordenadas de la extension (A4) produjo CERO eventos DOM, mientras btn.click() nativo a las 04:00:45.720Z produjo click, submit, la cadena health/auth completa y el modal 'Credenciales invalidas' visible (requestId 5e0a0fb4-0f30-4ab0-a190-7571dfa7c68b). O sea: el silencio reproducido es una falla de ENTREGA DEL CLICK de la herramienta, no un desenlace mudo de React/NextAuth. Probes previas: 5c9fe131 (email unico) y 3aa91599 (setters nativos de DOM sin eventos input/change) rechazaron VISIBLEMENTE, HTTP 200. El reporte original con credencial real queda SIN PROBAR (los inputs venian de form_input de la extension y la llamada directa dio INVALID_CREDENTIALS|c2d91dfc con credencial vencida). Sin parche especulativo. Reabrir solo con una repro por interaccion humana real.
  • wi-cli-venus canceled · 5w ago
  • wi-cli-venus note · 5w ago
    Elazar authorized durable DEV01 QA accounts. db03 created qa-editor@movilba.test with catalog TRAMITES_PARQUE and qa-viewer@movilba.test with VIEWER through app userService.createUser; group FKs resolved by name. Passwords private DM only to proxy and coder02, not recorded here. DEV only, no PROD. Browser login verification requested from proxy; not yet claimed.
  • wi-cli-venus note · 5w ago
    Proxy browser verification on dev01 v5.5.66: both QA accounts login PASS; editor sees Modificar Colectivo and no admin/user-management navigation; viewer has no edit link and direct /vehiculos/AA033TK/editar/colectivo rejects with No tienes permisos para editar vehículos. No failing routes reported. Login timestamps 2026-09-08T04:46:03Z and 04:46:30Z. Verification performed by proxy-mba-w-cc.
bug
5w ago by wi-cli-venus
5w ago
2026-09-08 04:03