[BUG] Per-view state lost on extension reload — no durable persistence

[easonLiangWorldedtech]

Problem

PR #966 introduced per-view state isolation (viewLocalState buffer), but this state is stored only in memory. On extension reload, all view-specific values are lost and fall back to shared global defaults.

This creates a "quiet reset" — worse than not having the feature at all:

• User opens tab A → selects mode architect, API config my-profile
• Extension reloads (e.g., VS Code restart, extension update)
• Tab A restores with shared global values (e.g., mode default, API config roo-code)
• User sees stale/wrong state without any indication that a reset occurred

Current Architecture

User Action → viewLocalState[key] = value  (in-memory buffer only)
                                    ↓
                         No write to durable storage
                                    ↓
Extension Reload → viewLocalState cleared → fallback to global defaults

loadViewState() reads from contextProxy.globalState, but per-view keys (__view_state_{id}_mode) are not included in GLOBAL_STATE_KEYS, so they're never restored.

Impact

Scenario	Before PR #966	After PR #966 (current)
Single tab, no reload	✅ Works	✅ Works
Parallel tabs, no reload	✅ Independent state	✅ Independent state
Extension reload	N/A (no per-view state)	❌ Stale values — worse than before

Proposed Fix

Store per-view state in vscode.workspaceState (or a dedicated durable key in contextProxy.globalState) so that:

1. View-specific mode/API config survives extension reload
2. loadViewState() can restore the correct values on startup
3. Parallel tabs maintain independent persistent state across restarts

Related

• Parent PR: #966 (introduces per-view isolation)
• Follow-up from edelauna review on fix(webview): isolate parallel provider view state #966

[taltas]

@zoomote , can you evaluate the proposed solution here? Don't actually attempt the fix.

[zoomote]

I'm on it. I started a task for this issue, and I'll keep updates here.

See task

[zoomote]

Evaluation of the proposed fix (reviewed against the PR #966 branch, pr-a-per-view-identity). Verdict: the bug is real, but the diagnosis is partly inaccurate, and the proposed fix as written would introduce new problems.

What's actually happening

The diagnosis "no write to durable storage" is only half correct:

• mode is already written durably. saveViewState("mode", ...) calls contextProxy.setValue("__view_state_{id}_mode", ...), which goes through ContextProxy.updateGlobalState → context.globalState.update(...). That is durable storage. The reload failure is on the read path: ContextProxy.initialize() only hydrates stateCache for keys in GLOBAL_STATE_KEYS, and getValue() reads from the cache, not from globalState directly. So after an extension-host restart the value exists in globalState but is invisible to loadViewState().
• currentApiConfigName / apiConfiguration are never persisted at all. They're only assigned to the in-memory viewLocalState (e.g. in upsertProviderProfile / activateProviderProfile); saveViewState is currently only called for mode. So for these the issue's description is accurate.
• syncViewStateToGlobal() exists but has no call sites (dead code).

So the observed symptom (silent fallback to shared defaults on reload) is correct, but the mechanism differs per key, which matters for choosing the fix.

Concerns with the proposed fix

1. workspaceState is the wrong memento. Mode/profile preference isn't workspace-scoped today — the fallback is shared global defaults. Moving view state to workspaceState would make the same tab restore different modes depending on which folder is open, and behaves differently in no-workspace/multi-root windows. globalState is the consistent choice.

2. Persisting apiConfiguration wholesale is a secret-leak risk. The full ProviderSettings object contains fields that ContextProxy normally routes to SecretStorage (API keys, etc.). Writing that object under a plain globalState key would store secrets unencrypted. Persist only currentApiConfigName per view and resolve the profile through ProviderSettingsManager on load — that also avoids stale copies when the profile is later edited.

3. The view id itself may not be durable. viewStateId is a random UUID stored in the webview's own vscode.getState() state. Webview-view state survives reloads in many cases (via WebviewViewResolveContext.state), but if the webview is recreated without its state (fresh window, state eviction), a new UUID is generated every time — per-view persistence then never restores, and orphaned __view_state_* keys accumulate in globalState forever. Any fix needs a story for key cleanup (enumeration via globalState.keys(), TTL, or a bounded map).

4. Scattered dynamic keys fight the ContextProxy design. __view_state_* keys bypass GLOBAL_STATE_KEYS, which means they're excluded from cache hydration (the actual bug), from getValues(), and from resetAllState() (so they'd survive a user-initiated state reset — stale state that even "reset everything" can't clear).

Suggested direction

Rather than workspaceState or ad-hoc dynamic keys, store one nested object under a single registered global-state key, e.g. viewStates: Record<viewStateId, { mode, currentApiConfigName }> added to GLOBAL_SETTINGS_KEYS. That gets cache hydration, getValues(), reset, export/import, and atomic cleanup for free, avoids the secrets problem by storing only the profile name, and gives one place to prune dead view ids. loadViewState() then reads viewStates[viewStateId] ?? shared defaults, and the ?? fallback stays as the backward-compat path.

Happy to review a PR along these lines.