vehiculos/[id] refreshes during active use - diagnostics added, root cause pending repro

Sub-tickets

Activity

• wi-cli-venus created · 7w ago
  parent=#3049
• wi-cli-venus assigned · 7w ago
  audit-mba-l-ca
• wi-cli-venus progress · 7w ago
  Repro captured by Elazar on dev01 /vehiculos/4093, DevTools console open. Timeline: session update() fired 13:51:07.977Z -> fetchVehiculo effect ran id=4093 (initial mount, expected). session update() fired again 13:56:14.426Z with NO navigation -> fetchVehiculo effect ran AGAIN for the same id=4093, userId unchanged, permissionsLoading=false both times. This is the reload: useSessionKeepAlive's update() call correlates 1:1 with a spurious re-run of the already-mounted page's fetchVehiculo effect, not a real navigation or id change. Points to the effect depending on session object identity (new reference each update() call) rather than a stable primitive (e.g. session.user.id). Next: read src/app/vehiculos/[id]/page.tsx effect deps + src/hooks/useSessionKeepAlive.ts update() call site to confirm identity-vs-value dependency and propose the fix.
• wi-cli-venus progress · 7w ago
  Traced effect deps in deployed code. page.tsx fetchVehiculo effect deps: [session?.user?.id, id, permissionsLoading, setBreadcrumbs, setPageTitle, router] - all primitives/stable, no object-identity dep. PermissionContext's own effect (line 195) has deps [session?.user?.id, status, fetchPermissions]; fetchPermissions is useCallback([session?.user?.id, session?.user?.email, setOffline]) and setOffline is useCallback in ConnectionContext, looks stable. So my earlier 'session object identity' hypothesis is wrong - none of the traced deps are referentially unstable by static read. The captured evidence (permissionsLoading=false logged both times, no true log) is consistent with permissionsLoading flipping true then back to false between the two logged runs (early-return guard swallows the true-state log) - i.e. PermissionContext's effect IS re-firing on session update(), but why is still open: either session?.user?.id or status briefly changes VALUE during useSession()'s update() cycle (not just reference), which static reading can't settle. Next step needs a runtime diagnostic inside PermissionContext's own effect (log session?.user?.id + status on every fire) deployed to dev01, or confirm via next-auth version docs whether update() transiently clears session data. Not fixed; correcting prior hypothesis, not closing.
• wi-cli-venus progress · 7w ago
  PM (Claude-in-Chrome trace) found the actual trigger: not our own effect deps as I traced, but next-auth's SessionProvider default refetchOnWindowFocus re-checking /api/auth/session on tab focus/visibilitychange - separate from useSessionKeepAlive's activity-based update(). That refetch produces a session update that re-fires the PermissionContext/fetchVehiculo chain, matching my earlier correlation but pinning the real source. No fixed timer, fires irregularly on focus. Fix candidate: throttle/guard the session recheck on visibilitychange, or debounce the resulting vehiculo re-fetch. Root cause found; closing out my open item.
• wi-cli-venus statusChanged · 7w ago
• wi-cli-venus progress · 7w ago
  Confirmed Chrome trace root cause: NextAuth /api/auth/session visibility/focus recheck caused an in-place vehicle detail refetch; not a page reload and no fixed timer. DEV candidate b8b87266/v5.4.57 adds stable userId:vehicleId request-key guard while preserving focus session security, removes all temporary diagnostics, and passed lint/typecheck; live serviceId 8720, refs agree. Authenticated focus/network trace requested from audit: session call allowed, vehicle/detail-dropdown refetch and spinner forbidden; route change must still fetch.
• wi-cli-venus verified · 7w ago
  Static/deployed audit PASS on DEV b8b87266/v5.4.57: exact four-file diff, refs/version/health verified; stable request key is set synchronously pre-await, same-key branch returns before setLoading, error reset is key-safe, user/vehicle changes refetch, and no legitimate same-route refresh flow exists. Coverage boundary: audit lacks authenticated Chrome and could not repeat focus/blur Network trace. Final runtime repro requested from PM's Claude-in-Chrome session that captured the original failure.
• wi-cli-venus verified · 7w ago
  DECISIVE authenticated runtime PASS from Elazar/Claude-in-Chrome on fresh DEV v5.4.57 b8b87266: observed ~114 seconds after reload; zero post-load vehicle or session data fetches, no refresh diagnostic, no visible reload, and no repeated reconnect cycle. A single ~21s connection/error-handler reinitialization caused no data fetch and did not recur for ~90s; tracked as separate non-blocking artifact. Combined with prior static/deployed audit PASS, DEV gate is complete; PROD scope requested.
• wi-cli-venus progress · 7w ago
  Elazar GO executed: canonical PROD deploy 5d73e70af308111ac153bbbef3656c16f86aabcd, v5.4.57/serviceId 8720; typecheck PASS; lezama/main=origin/main; merge tree equals audited DEV b8b87266. Fresh authenticated DEV runtime trace already PASSed focus/refetch behavior. Independent PROD deployed-diff/runtime audit requested.
• wi-cli-venus note · 7w ago
  Canonical PROD promotion completed for runtime-PASS M137 fix plus reviewed M89 docs. Typecheck and synchronized-ref checks passed; Validadoras remains hidden. Independent PROD deployed-diff/runtime verification requested, including M128 gate and M42 regression checks.
• wi-cli-venus verified · 7w ago
  Independent PROD audit PASS: origin/main 5d73e70a, v5.4.57, live serviceId 8720; deployed diff exactly matches the previously audited M137 fix, /validadoras remains 404, and no regression was found. Authenticated DEV focus trace on identical code remains the runtime evidence because no authenticated PROD browser session was available.
• wi-cli-venus completed · 7w ago
  Verificado/deployado v5.4.57, confirmado por audit-mba-l-ca 2026-08-28.