Summary
A same-user token refresh can occur while an unchanged route's initial store read is still pending. Several ownership corrections correctly invalidate the old-token request and preserve already settled cache data, but an empty first-load surface has nothing to preserve. If the view only fetches on mount or route/filter changes, the old result is ignored and no new-token read is issued, leaving a false empty or blank route.
This residual was confirmed by Codex review on PR #3338 at corrected head c48346128982366c0abdf4f1f766246f5cc351dc. AgentsView, AgentRunsView, and AgentRunDetailView do not refetch merely because session.token changes. The current regression seeds existing data before rotation, so it proves cache preservation but not unresolved initial load recovery.
Potentially affected active ownership work
Feature-flag persistence PR #3351 is not part of this request lifecycle pattern.
Required contract
For a token-only rotation where user identity/auth/demo state is unchanged:
- Already settled data remains visible.
- An active latest read for an unresolved/empty surface is either preserved as authoritative for the same user or restarted under the new token.
- If restarted, the old request still settles to its original caller but cannot patch state, error, toast, or loading.
- Retry ownership belongs to the new token/lifecycle; its success and failure behave like an ordinary current request.
- Route-clear helpers and full identity/auth/demo replacement must invalidate work without restarting it.
- A newer route/filter read must still supersede both the original and any refresh retry.
- No refresh loop, duplicate settled-cache refetch, or unhandled retry rejection.
Acceptance
- Deferred real-Pinia regressions for an empty initial surface with a read in flight when the token rotates.
- The API is called again only where restart is required; loading remains truthful until the new-token owner settles.
- Old-token success and failure are suppressed after restart.
- New-token success populates the unchanged route; new-token failure produces current error/toast state.
- Existing loaded-data preservation, reverse-settlement, route-clear, mutation-generation, logout/login, demo, and independent-lane tests remain green.
- Each affected PR keeps its own test and exact-head qualification so stacked ownership remains reviewable.
Boundaries
This is client read-lifecycle recovery. It does not require transport cancellation, automatic mutation replay, token revocation, or cross-tab synchronization. Mutations already sent before refresh must not be silently retried by this issue.
Audit provenance
Seeded from the repeat Codex review on #3338 after the 2026-09-21 asynchronous ownership pass distinguished full identity replacement from same-user credential rotation.
Summary
A same-user token refresh can occur while an unchanged route's initial store read is still pending. Several ownership corrections correctly invalidate the old-token request and preserve already settled cache data, but an empty first-load surface has nothing to preserve. If the view only fetches on mount or route/filter changes, the old result is ignored and no new-token read is issued, leaving a false empty or blank route.
This residual was confirmed by Codex review on PR #3338 at corrected head
c48346128982366c0abdf4f1f766246f5cc351dc.AgentsView,AgentRunsView, andAgentRunDetailViewdo not refetch merely becausesession.tokenchanges. The current regression seedsexistingdata before rotation, so it proves cache preservation but not unresolved initial load recovery.Potentially affected active ownership work
Feature-flag persistence PR #3351 is not part of this request lifecycle pattern.
Required contract
For a token-only rotation where user identity/auth/demo state is unchanged:
Acceptance
Boundaries
This is client read-lifecycle recovery. It does not require transport cancellation, automatic mutation replay, token revocation, or cross-tab synchronization. Mutations already sent before refresh must not be silently retried by this issue.
Audit provenance
Seeded from the repeat Codex review on #3338 after the 2026-09-21 asynchronous ownership pass distinguished full identity replacement from same-user credential rotation.