Session View Navigation Stale Data Automation: The URL Moved, the Screen Didn't

Preventing a data-fetching effect from firing twice on a component's initial mount — a common annoyance in React applications, especially under strict development-mode double-invocation — is a reasonable thing to want, and a one-shot guard (a reference value checked and flipped before the first real call) is a common way to get it. The risk is specific to what happens to that same guard on every call AFTER the first one: if the guard's only job is "has this ever run before," rather than "has this run for the CURRENT set of inputs," it will keep blocking the fetch forever, even when the actual data the component needs to display has completely changed underneath it — a scenario every bit as real as the duplicate-fetch-on-mount problem the guard was built to solve, just less obvious during ordinary testing.

Centriu Axiom's session-detail view reads a session's own data — its structured checklist, action cards, recommendations, chat history — through a dedicated hook that exposes a `load` function responsible for fetching everything the screen needs for a specific session, identified by the session ID present in the current URL. That `load` function is built as a `useCallback` with a dependency array of `[sessionId]` — meaning React gives the hook a genuinely NEW function reference every single time the session ID actually changes, which is precisely the mechanism that should make the screen able to fetch a different session's data on navigation, without requiring a full page reload.

Before this fix, the effect actually calling `load()` was gated behind a one-shot guard: a `useRef(false)` value, checked with `if (!loadedRef.current)` immediately inside the effect, set to `true` the moment the very first call to `load()` fired, and never reset afterward for the remaining life of the component. The guard's own evident purpose was avoiding a duplicate fetch firing on the component's initial mount — a real, if minor, concern in a React application. The side effect, however, was structural: because `loadedRef.current` becomes `true` after the very first successful call and never changes back, EVERY subsequent invocation of that same effect — including every one triggered by `load` itself being recreated with a fresh `sessionId` — hits the guard's check, finds it already `true`, and silently does nothing at all. The genuinely new `load` function, correctly built to fetch a genuinely new session's data, was constructed and then never actually called.

The practical consequence surfaces specifically on a same-page navigation between two different sessions' detail views — a person clicking from one session directly into another, using an in-app link rather than a full browser reload. Centriu Axiom's client-side router, like most modern single-page applications, reuses the identical mounted `SessionView` component instance across this kind of navigation between two routes sharing the same URL pattern, rather than tearing it down and building a fresh one — an entirely standard and usually invisible optimization. Because the SAME component instance persists across the navigation, its internal `loadedRef`, permanently `true` since the very first session anyone viewed in that browser tab, persists right along with it. The URL updates to reflect the new session ID. The breadcrumb, the page title, and any other UI driven directly by route parameters update correctly, because those read the URL directly rather than going through the gated fetch. The actual session content — the checklist, the action cards, the chat history, everything the screen exists to display — stays completely frozen on whichever session was first ever viewed in that tab, because the guard silently refused to let the new session's own fetch run at all.

The fix removes the one-shot guard entirely. The effect now simply calls `load()` every time it runs, with no conditional check in front of it — and because `load` is only ever recreated (a new function reference, triggering the effect to re-run) when `sessionId` genuinely changes, the fetch now runs exactly once per real session change: once on the component's initial mount (correctly fetching the first session), and again every time the session ID in the URL subsequently changes (correctly fetching each new session), with no duplicate firing and no stale data left behind. The dependency mechanism that was already correctly built (`load`'s own `[sessionId]` dependency) turns out to be sufficient on its own to prevent unnecessary duplicate fetches, without needing the separate one-shot guard that had been layered on top of it.

Before the fix, someone reviewing Centriu Axiom's session list, opening one session's detail view, and then clicking directly into a second, entirely different session from within that same view — without a full page reload — would see the URL and breadcrumb correctly reflect the second session, while the actual displayed checklist, action cards and chat history remained exactly as they were for the FIRST session viewed in that browser tab, regardless of how many different sessions were clicked into afterward. After the fix, each click into a different session's detail view correctly fetches and displays that session's own real data, every time.

Centriu Axiom's session-detail view now correctly fetches a session's own data on every genuine navigation to a different session — including same-page, client-side navigation directly between two sessions' detail views — closing a gap where a one-shot fetch guard, built for an unrelated initial-mount concern, could silently strand the screen on the very first session ever viewed in a browser tab regardless of how many different sessions were subsequently navigated to.

This automation governs Centriu Axiom's own internal session-detail data-fetching logic specifically — it does not change what data a session's detail view displays or how a session is structured, and a workflow that always fully reloads the page between viewing different sessions (rather than navigating directly between them client-side) would never have encountered this specific defect, since a full reload always creates a fresh component instance with its own guard starting fresh.

A one-shot guard checked once and never reset is the simplest way to prevent a specific, narrow duplicate-call scenario (a component's own initial mount, particularly under development-mode double-invocation) — and it is genuinely effective for exactly that scenario. The same guard becomes actively harmful the moment the component is reused across a change in the actual data it should be displaying, because the guard has no way to distinguish "already ran once, ever" from "already ran for the CURRENT input." A dependency array on the fetch function itself, already correctly built to change identity when the relevant input (the session identifier) changes, does the narrower, more correct job on its own — re-running exactly once per genuine change, with no separate guard needed at all.