El bucle de la ficha vuelve entero deslogueado: la guarda solo frenaba el camino de exito
El bucle de MOVILBA-135 volvia ENTERO por el camino deslogueado, y el arreglo de v5.5.6 no lo tocaba porque la guarda que lo frenaba solo existia en el camino de EXITO. MECANISMO: resolverVehiculoPorDominio (src/actions/vehiculos.ts:612) devuelve {success:false,'No autorizado'} DETERMINISTICAMENTE cuando auth() no trae sesion. La guarda dominioResueltoRef se tomaba antes de llamar a la accion, y en el fallo se LIBERABA, con un comentario que sonaba correcto ("un fallo no puede dejar el dominio marcado como resuelto"). Entonces: fallo -> guarda liberada -> router.push('/404') -> payload RSC nuevo -> params con identidad nueva -> la accion otra vez, a ~1-1.5s por vuelta. La guarda estaba estructuralmente ausente exactamente en el caso que falla SIEMPRE. POR QUE NO SE VIO: mi repro de v5.5.6 fue LOGUEADO. Claude-in-Chrome lo reprodujo solo deslogueado, con las tabs logueadas limpias 35s. Un repro que no toca la rama que falla no es evidencia sobre esa rama. ARREGLO, en tres archivos - [dominio]/page.tsx, [dominio]/editar/page.tsx, [dominio]/editar/colectivo/page.tsx: 1. !resultado.success ya no libera la guarda ni empuja a /404: un fallo de sesion/permiso/servidor no es un 404, y reintentar contra un fallo deterministico es pura amplificacion. Sale un console.warn. 2. Solo success && vehiculoId == null (no encontrado de verdad) empuja a /404. 3. La resolucion no corre si status !== 'authenticated'; el caso deslogueado tiene UN dueno, el efecto que empuja a /user/login. 4. La guarda se libera en la TRANSICION !authenticated -> authenticated (sesion que muere a mitad del montaje y vuelve), nunca en el fallo. El efecto que libera se declara ANTES del que resuelve: los efectos corren en orden de declaracion, y al reves andaba solo porque la escritura de la guarda cae despues del await params - correccion apoyada en un await es correccion que el proximo editor rompe sin enterarse (lo trajo audit sobre v5.5.13). Versiones: v5.5.12 el nucleo, v5.5.13 el dueno del caso deslogueado en las dos rutas de edicion mas la recuperacion por transicion, v5.5.14 el orden de declaracion. Auditado por audit-mba-l-cc en los tres shas (c4e30d8f / d1dcec3e / c368338e) y CERRADO de su lado. VERIFICADO por proxy-mba-w-cc en dev01 v5.5.14 con las tres URLs deslogueadas: un solo GET, redirect del servidor a /user/login?callbackUrl=..., sin POST, sin pares POST+?_rsc= repetidos, y se queda ahi. Consola: una sola linea. NO EJERCITADO: ningun repro de navegador propio, ni logueado ni deslogueado, en ninguna version. Lo que quedo del lado logueado se midio aparte y NO es este bucle.
Activity
-
El bucle de la ficha vuelve entero deslogueado: la guarda solo frenaba el camino de exito
-
was: MEDIDO por proxy-mba-w-cc en dev01 el 2026-09-07 con sesion VALIDA, despues del arreglo de MOVILBA-307. Claude-in-Chrome lo reporto como "el bucle sigue logueado", y la medicion dice que NO es el bucle: es una cascada ACOTADA que termina sola. Las cifras, dos vehiculos distintos: - /vehiculos/AE801OE: 19 requests POST/GET(?_rsc=) alternados, todos entre 1235 y 2812ms desde el inicio de la navegacion, y despues NADA por mas de 20s. - /vehiculos/AA033TK: 18 requests, 1120-2467ms, misma forma. O sea no es de un dominio en particular. Por que NO es MOVILBA-135 ni MOVILBA-307, y es la parte que decide: los intervalos son de 27-80ms con algunos huecos de 176-301ms. El bucle de 135 corria a ~94ms parejo y sin fin; el de 307 a ~1-1.5s y sin fin. Tercer intervalo, tercera forma, tercer motor. Y sobre todo: TERMINA. La firma de un bucle es repeticion sin cota, no un pico. Lo demas de la medicion: la barra de direcciones nunca se movio de la ficha, la pagina renderizo los datos correctos y distintos para cada vehiculo, sin spinner, y "Global error handlers initialized" salio UNA vez en AE801OE y DOS en AA033TK (o sea hubo un remontaje ahi, sin ninguna otra diferencia de comportamiento). Los 12 errores 503 del run cayeron todos en prefetches paralelos de OTRAS rutas, 0 de 19 en la ficha. EL MECANISMO, y hay que confirmarlo antes de tocar nada: la ficha dispara varias Server Actions en el montaje - resolverVehiculoPorDominio, obtenerComentariosImportacion, getVehiculoCadena, getFechaAltaMasReciente - y Next transporta CADA accion como un POST a la URL de la ruta, cada uno seguido del GET ?_rsc= con que el router refresca el payload. N acciones son 2N requests aunque ninguna se llame a si misma. Eso explica la cota y explica por que termina: los efectos dependen de `id`, que se estabiliza. ESTADO: no es un defecto de correccion. La pagina anda y muestra bien. Es desperdicio - cada vuelta paga auth() + hasPermission + una consulta, y en PROD el rol de runtime tiene statement_timeout=5s. Prioridad baja a proposito. NO EJERCITADO: nadie confirmo el mecanismo contra los logs del servidor; la explicacion de arriba es lectura de codigo mas la forma de la traza del navegador. Antes de "arreglarlo" hay que contar las invocaciones del lado del servidor y ver CUALES son las 9-10 acciones, porque cuatro acciones no dan 19 requests sin algo mas. Medir primero.
-
Shipeado v5.5.12/13/14, auditado en los tres shas y verificado deslogueado por proxy en dev01 v5.5.14.