# Session lifetimes fence client work

> Source: https://github.com/max-listov/stitchkit/blob/master/docs/decisions/0207-session-lifetimes-fence-client-work.md

---

# Session lifetimes fence client work

## Decision

A login lifetime is distinct from an authorization owner: signing into the same
account creates a new lifetime. `createSessionScope` owns that lifetime; a captured
operation owns an opaque instance ID, generation, cancellation signal and explicit
checks. Request attempts use `bindFetch`, complete asynchronous calls use `run`,
and the final synchronous state mutation or transport send uses `deliver`.
Neither cancellation nor freshness checks undo server-side effects.

`createSessionCredentials` uses the same scope, a refresh flight per generation,
and the neutral internal mutation queue also used by agent run mutations. Only
storage work enters that queue. Logout invalidates memory synchronously; ordered,
generation-checked writes and clears prevent an old operation from overwriting a
later successful login. Storage failures and capacity refusals remain caller-visible.
Refresh has a deadline and does not retry application commands. The host classifies
auth failures and owns any one-shot retry policy; `403` alone is not that policy.

The coordinator owns one client instance. Shared browser tabs, processes and secure
storage providers require their own locking/CAS contract. Contexts and credentials
must be treated as immutable. All credential writes must use this coordinator.

## Consequences

Existing clients and auth providers remain usable. Adoption replaces local lifetime
counters and refresh/storage coordinators; it does not introduce a second client,
RPC dispatcher, global auth store or provider-specific login policy.

Invariants: I8, I10, I12, I13.