Repository navigation
[Maintainability] Centralize Global Ask session storage access #359
Description
Problem
AskAgentPanel defines GLOBAL_ASK_SESSION_STORAGE_KEY but two new write/remove paths still repeat the literal "lineageweave.globalAskSessionId". The values currently match, so runtime behavior is correct, but a future key migration could silently split read, write, and invalidation behavior.
Required change
- Route every read, write, and removal through the shared constant or a small typed storage adapter.
- Keep current 404 session-recovery and 409 stale-session retry behavior.
- Do not clear unrelated session-storage entries.
- Do not change the server session contract or remove recovery behavior.
Acceptance
- a source/behavior regression prevents a second hardcoded key from being introduced;
- successful answers persist the returned session ID;
- 404 recovery removes the same key and retries once without a session;
- 409 recovery removes the same key and retries once;
- malformed or unavailable storage fails safely without losing the current Ask answer;
- frontend tests, lint, production build, and Storybook pass.
Origin
Tracked from the exact-head review of PR #342. It is a maintainability hardening item, not a reason to roll back the Global Ask session-recovery feature.
Activity
seonghobae commentedon Aug 22, 2026
The shared storage-key behavior is implemented in stacked PR #353: AskAgentWorkspace routes get, set, and remove through GLOBAL_ASK_SESSION_STORAGE_KEY and carries focused recovery tests. #353 merged into a non-main stack branch; protected main exact head ef6f5a5 does not yet contain it. Keeping this issue open until protected-main integration and exact-head frontend, build, and Storybook verification complete.
seonghobae commentedon Aug 23, 2026
Current product-line correction: #490 exact head
fc3ea87470dc840e38aa36f9f0c25294c334734cfollows ADR 0126 and uses account-owned server conversation history; it no longer has a browserlineageweave.globalAskSessionIdread/write/removal contract to centralize. Reintroducing a storage adapter would duplicate and conflict with that accepted persistence boundary. Treat this maintainability item as superseded once the ADR 0126 line reaches protected main; no protected merge is claimed here.seonghobae commentedon Aug 25, 2026
Closed as superseded by the protected-main ADR 0126 server-owned conversation boundary. Current protected main contains neither GLOBAL_ASK_SESSION_STORAGE_KEY nor the former lineageweave.globalAskSessionId browser-storage key, so adding an adapter would recreate the obsolete client persistence contract. Async Ask durability now uses normalized server-side job/session state instead.