Skip to content

Same-user token refresh can strand empty first-load store surfaces #3352

Description

@Chris0Jeky

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:

  1. Already settled data remains visible.
  2. An active latest read for an unresolved/empty surface is either preserved as authoritative for the same user or restarted under the new token.
  3. If restarted, the old request still settles to its original caller but cannot patch state, error, toast, or loading.
  4. Retry ownership belongs to the new token/lifecycle; its success and failure behave like an ordinary current request.
  5. Route-clear helpers and full identity/auth/demo replacement must invalidate work without restarting it.
  6. A newer route/filter read must still supersede both the original and any refresh retry.
  7. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingfrontendPrimary implementation impact in Vue/TypeScript UI and client runtime.testingTest coverage, harnesses, regression prevention, and verification pipeline work.

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions