Give session authority and lifecycle one owner #67
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem and evidence
Session authorization is interpreted across storage and stream/session code. Refresh revokes the previous access token and advances its authorization epoch in
crates/server/src/storage/mod.rs:2589+;session_creator_authorizationseparately follows a live refresh-family successor at:1919-1945. Persistent-session coverage and termination attribution live incrates/server/src/stream.rs, while stream admission and revalidation have separate transition logic. There is no shared SessionAuthority/SessionLifecycle owner.Recommendation
Extract one authority model for stable login-family identity plus current role/scope/epoch, with an adapter for temporary access-token validity. Give session lifecycle transitions one owner for admission, persistence, close, termination and audit. Keep transitions shared by embedded and remote routes.
Payoff and estimate
A session change has one transition model to review, reducing refresh, replay, revocation and cleanup regressions. Estimate: 4–7 engineering days. Completion evidence: existing races and cleanup/audit behavior pass through the shared transitions on both routes; module moves alone do not count.
Priority: Next milestone (PLAN steps 5/7).
2026-10-04 owner decisions: Matches the owner’s signed-RPC, revocation-fence and persistent-session security model. Preserve current semantics; no indefinite session permission is implied.
Report: arch-review report
Source: arch-review 2026-10-04
Performance evidence to fold into this issue
The 2026-10-04 perf audit measured 16,324 separately echoed one-byte input DATA frames over 16.37 s. The full echo path used 6.371B instructions and 13.666 CPU seconds; SQLx accounted for 32.96% of sampled CPU and SQLite native symbols 2.99% inclusive. WAL size and salts were unchanged (300 frames / 1,236,032 bytes before and after). VM load1 moved from 6.98 to 6.38. The profile is named-input-fences.svg; exact run data is in audit-results.json. This profile covers the full echo path, not only the admission transaction.
Current admission calls SqliteStorage::admit_stream_data for each ready inbound batch, opens BEGIN IMMEDIATE, validates the authorization snapshot and commits around synchronous enqueue (crates/server/src/storage/mod.rs:2011-2034; crates/server/src/stream.rs:1589-1632). The batching change helps frames already ready together; sparse one-byte input still commonly admits one frame per batch.
Please include the measured cost in #67's acceptance: investigate a cached/in-memory authorization epoch or equivalent admission path coordinated with every authorization write, and compare it on the same sparse-input workload. Preserve the revocation barrier and fail-closed behavior.
Payoff: reduce the measured 32.96% SQLx CPU share on sparse interactive input; no exact gain is claimed until an A/B.
Quick win vs deeper change: no safe query-removal quick fix is established. A ≤½-day trace/repro can localize the remaining work; the deeper change is estimated at 2–4 days. Risk: high authorization-race risk; retain the independent Sol-tier security review and race tests.
Priority: Next milestone.
2026-10-04 owner decisions: Matches the signed-RPC, revocation-fence and audit security model. This is evidence for the existing #67 authority work, so I am adding it here rather than creating a duplicate.
Report: perf-audit report
Source: perf-audit 2026-10-04