fix(webview): add durable per-view state base - #977
fix(webview): add durable per-view state base#977easonLiangWorldedtech wants to merge 18 commits into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds durable per-view state schemas, identifiers, persistence, restoration, and state merging across webview and extension layers. It also adds task-specific API controls, browser storage fallbacks, and parallel-view integration coverage. ChangesPer-view state and task control
Estimated code review effort: 5 (Critical) | ~90 minutes Sequence Diagram(s)sequenceDiagram
participant Webview
participant ExtensionStateContext
participant webviewMessageHandler
participant ClineProvider
participant globalState
Webview->>ExtensionStateContext: obtain stable viewStateId
ExtensionStateContext->>webviewMessageHandler: webviewDidLaunch with viewStateId
webviewMessageHandler->>ClineProvider: setViewStateId(viewStateId)
ClineProvider->>globalState: load or save viewStates
ClineProvider-->>Webview: merged view-local state
Possibly related issues
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (2 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://cdn.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/core/webview/ClineProvider.ts`:
- Around line 3005-3056: Update resetState(), activateProviderProfile(),
upsertProviderProfile(), and deleteProviderProfile() to clear or synchronize the
affected viewLocalState fields after mutating contextProxy. Reuse
_clearViewLocalState() for resetState() and _updateViewLocalStateFromMutation()
or equivalent targeted invalidation for profile changes, ensuring stale
currentApiConfigName and apiConfiguration values cannot mask the updated global
state.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 58c5e801-f818-415c-b0de-9f69e7498604
📒 Files selected for processing (13)
packages/types/src/__tests__/index.test.tspackages/types/src/global-settings.tspackages/types/src/vscode-extension-host.tssrc/core/webview/ClineProvider.tssrc/core/webview/__tests__/ClineProvider.parallelMode.spec.tssrc/core/webview/__tests__/ClineProvider.spec.tssrc/core/webview/__tests__/ClineProvider.sticky-mode.spec.tssrc/core/webview/__tests__/webviewMessageHandler.spec.tssrc/core/webview/webviewMessageHandler.tswebview-ui/src/App.tsxwebview-ui/src/__tests__/App.spec.tsxwebview-ui/src/context/ExtensionStateContext.tsxwebview-ui/src/utils/vscode.ts
💤 Files with no reviewable changes (1)
- webview-ui/src/App.tsx
github-actions
Bot
added
the
awaiting-review
edelauna
left a comment
edelauna
left a comment
There was a problem hiding this comment.
Exciting to see this work come together! Had some implementation comments, and can we also add some ui testing:
We can leverage the UI testing setup established in McpServerRestriction.spec.tsx and webview-ui/src/utils/test-utils.tsx:
-
ExtensionStateContext.ProviderWrapper Pattern:
Re-use therenderWithStatepattern to mount webview components with specificviewStateIdprops and verify that UI components respond correctly to view-localmodeandcurrentApiConfigNamestate without global bleed. -
Reseed & Identity Tests:
Similar to the slug-change reseed tests inMcpServerRestriction.spec.tsx, add UI-level tests inExtensionStateContext.spec.tsxorApp.spec.tsxto verify that whenviewStateIdchanges or a webview reloads, local React state reseeds properly from the new view'sviewStateIdpayload. -
vscode.getViewStateId& Messaging Spies:
Ensure UI tests verifyVSCodeAPIWrapper.getViewStateId()fallback behavior whensessionStorage/localStorageare restricted or cleared.
| return viewStates | ||
| } | ||
|
|
||
| private async savePersistedViewState(values: Partial<PersistedViewState>): Promise<void> { |
There was a problem hiding this comment.
savePersistedViewState reads the global viewStates dictionary from contextProxy, mutates states[this.viewStateId] in memory, and writes it back asynchronously via await contextProxy.setValue("viewStates", ...). When concurrent webview instances update mode or API profile selections simultaneously, one instance reads stale global state before the other's write completes, causing a lost update on viewStates.
| @@ -2864,6 +3082,7 @@ export class ClineProvider | |||
| } | |||
|
|
|||
| await this.contextProxy.resetAllState() | |||
There was a problem hiding this comment.
resetState() clears global settings in contextProxy but does not clear this.viewLocalState (e.g., via _clearViewLocalState()). When getState(viewStateId) runs, it merges stale viewLocalState overrides over the reset contextProxy defaults, causing pre-reset or deleted profile settings to persist in active webview instances.
| * profile upsert/activation/deletion, or resetState. This ensures the local cache stays in | ||
| * sync with global state changes that would otherwise be invisible behind mergedStateValues. | ||
| */ | ||
| private _updateViewLocalStateFromMutation(values: Partial<RooCodeSettings>): void { |
There was a problem hiding this comment.
_updateViewLocalStateFromMutation updates in-memory viewLocalState in response to setValue/setValues calls, but never invokes savePersistedViewState. Mutations made via setValue/setValues are held only in memory and lost when the webview reloads or VS Code restarts.
|
|
||
| describe("local state isolation", () => { | ||
| it("should isolate mode state between instances", async () => { | ||
| const provider1 = new ClineProvider( |
There was a problem hiding this comment.
The test 'should isolate mode state between instances' reads the initial mode of two provider instances without mutating mode in either, making it incapable of verifying whether mode changes in one instance leak to other instances.
| vi.mocked(mockClineProvider.contextProxy.getValue).mockReturnValue("shared-profile") | ||
| vi.mocked(mockClineProvider.contextProxy.setValue).mockResolvedValue(undefined) | ||
| }) | ||
|
|
There was a problem hiding this comment.
The webviewDidLaunch handler test passes viewStateId: 'view-1' but omits an assertion verifying that provider.setViewStateId was called with 'view-1'.
github-actions
Bot
added
awaiting-author
82f9f23 to
d724948
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/core/webview/__tests__/ClineProvider.parallelMode.spec.ts (1)
1098-1195: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider adding coverage for the two uncovered profile-mutation paths.
None of these tests exercise
upsertProviderProfile(..., false)(non-activating save) or adeleteProviderProfilecase whereviewLocalState.currentApiConfigNamediverges from the global value - both are the exact gaps flagged insrc/core/webview/ClineProvider.ts(upsertProviderProfile/deleteProviderProfile). Adding cases here would catch regressions on those fixes.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/core/webview/__tests__/ClineProvider.parallelMode.spec.ts` around lines 1098 - 1195, The profile-mutation tests cover only activating upserts and matching delete state; add coverage for the two missing branches. In the “profile mutations” suite, add a test for upsertProviderProfile(..., false) that verifies the saved profile does not activate or incorrectly synchronize current state, and a deleteProviderProfile test where viewLocalState.currentApiConfigName differs from the global ContextProxy value, asserting the intended local-state behavior after deletion.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/core/webview/__tests__/ClineProvider.parallelMode.spec.ts`:
- Around line 1098-1195: The profile-mutation tests cover only activating
upserts and matching delete state; add coverage for the two missing branches. In
the “profile mutations” suite, add a test for upsertProviderProfile(..., false)
that verifies the saved profile does not activate or incorrectly synchronize
current state, and a deleteProviderProfile test where
viewLocalState.currentApiConfigName differs from the global ContextProxy value,
asserting the intended local-state behavior after deletion.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 1c33c4bc-cef3-4dc5-a6f1-07927265c1e5
📒 Files selected for processing (6)
src/core/webview/ClineProvider.tssrc/core/webview/__tests__/ClineProvider.parallelMode.spec.tssrc/core/webview/__tests__/webviewMessageHandler.spec.tswebview-ui/src/context/__tests__/ExtensionStateContext.spec.tsxwebview-ui/src/utils/__tests__/vscode.spec.tswebview-ui/src/utils/vscode.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/core/webview/tests/webviewMessageHandler.spec.ts
github-actions
Bot
added
the
awaiting-author
github-actions
Bot
added
awaiting-review
edelauna
left a comment
edelauna
left a comment
There was a problem hiding this comment.
Couple more comments - thanks for continuing to iterate on this.
| const state2 = await provider2.getState() | ||
|
|
||
| expect(state1.mode).toBe("architect") | ||
| expect(state2.mode).toBe("code") |
There was a problem hiding this comment.
Does this actually prove isolation? provider2 starts at "code" (the global default) and is never mutated, so this assertion passes whether or not the two instances share state. Would it be more meaningful to first set provider2 to a distinct non-default mode (e.g. "debugger"), then mutate provider1, then assert provider2 still reads "debugger"?
There was a problem hiding this comment.
Already addressed — the isolation test now sets the second provider to a distinct non-default mode before mutating the first provider. Specifically, provider2 is set to debugger, then provider1 is set to architect. The assertions then verify provider1 reads architect while provider2 still reads debugger.
So the test now proves instance isolation with two distinct non-default/local states instead of relying on the global default.
|
|
||
| expect(state.apiConfiguration.apiProvider).toBe("bedrock") | ||
| expect(state.apiConfiguration.awsBedrockEndpoint).toBe("http://127.0.0.1:4567") | ||
| expect((provider as any).viewLocalState.apiConfiguration.apiProvider).toBe("bedrock") |
There was a problem hiding this comment.
The test confirms the new bedrock keys are present, but the PROVIDER_SETTINGS_KEYS merge at line 3118 of ClineProvider.ts spreads onto the existing viewLocalState.apiConfiguration — so stale keys from the previous provider (e.g. openRouterModelId) could survive. Worth adding expect((provider as any).viewLocalState.apiConfiguration).not.toHaveProperty("openRouterModelId") here?
There was a problem hiding this comment.
Fixed — added the stale-key assertion on line 1068, so the test now verifies that switching from OpenRouter to Bedrock removes the previous OpenRouter model key. The implementation already handles this on line 3143: when a flat provider-settings update includes the provider field, it replaces the local API configuration instead of merging into the existing one, so stale provider-specific keys cannot survive. Verified with the parallel-mode spec: 42 tests passed.
| const wrapper = new VSCodeAPIWrapper() | ||
|
|
||
| expect(wrapper.getViewStateId()).toBe("memory-view") | ||
| expect(wrapper.getViewStateId()).toBe("memory-view") |
There was a problem hiding this comment.
crypto.randomUUID is mocked to always return "memory-view", so calling getViewStateId() twice will return the same string regardless of whether the early-return guard (that reads the stored ID) is present or not. What if the mock returned a different value on the second call — would the second getViewStateId() still return "memory-view"?
There was a problem hiding this comment.
Fixed — the UUID mock now returns different values on subsequent calls (line 64). The assertions on lines 83-85 verify that the second call still returns "memory-view" and that UUID generation only happens once, so the test now proves the stored/in-memory ID is reused rather than regenerated. Verified: 3 tests passed.
|
|
||
| vi.mock("../../task-persistence", () => ({ | ||
| readApiMessages: vi.fn().mockResolvedValue([]), | ||
| saveApiMessages: vi.fn().mockResolvedValue(undefined), |
There was a problem hiding this comment.
The production code replaces non-alphanumeric/dash characters with underscores: .replace(/[^A-Za-z0-9_-]/g, "_"). All calls here use already-clean IDs — is there a test somewhere that passes a raw ID containing spaces, dots, or slashes to verify the sanitization actually runs and that the sanitized form is the key used in viewStates?
There was a problem hiding this comment.
Yes — there is coverage for this now. The test at ClineProvider.parallelMode.spec.ts passes a raw view state ID containing a slash, dot, and spaces: tab panel/with.dots and spaces. It then verifies that the persisted viewStates key is the sanitized form on ClineProvider.parallelMode.spec.ts, and also verifies the raw unsanitized key is not present on ClineProvider.parallelMode.spec.ts. The parallel-mode spec was verified passing with 42 tests.
| private async savePersistedViewState(values: Partial<PersistedViewState>): Promise<void> { | ||
| const write = ClineProvider.persistedViewStateWriteQueue.then(async () => { | ||
| const states = this.getPersistedViewStates({ fresh: true }) | ||
| const current = states[this.viewStateId] ?? {} |
There was a problem hiding this comment.
this.viewStateId is read inside the .then() closure at execution time. If setViewStateId() fires between when this write is enqueued and when the queue runs it, the write would land under the new ID rather than the one that was active when the change was made. Should viewStateId be captured before the .then() (e.g. const viewStateId = this.viewStateId at the top of savePersistedViewState)?
There was a problem hiding this comment.
Yes — fixed. savePersistedViewState now captures the active viewStateId before the queued write is created on line 454, and the queued closure uses that captured ID on lines 457-458 instead of reading this.viewStateId later: ClineProvider.ts.
There is also regression coverage starting on line 1115: ClineProvider.parallelMode.spec.ts. The test starts a save under view-a on line 1139, switches to view-b before the queued write completes on line 1141, then verifies the write lands under view-a on lines 1145-1148: ClineProvider.parallelMode.spec.ts.
| if (value === undefined || value === null) { | ||
| delete this.viewLocalState[key] | ||
| } else { | ||
| this.viewLocalState[key] = value |
There was a problem hiding this comment.
viewLocalState is updated here before savePersistedViewState is awaited. If the durable write fails, the in-memory state is ahead of what was persisted — on next reload viewLocalState would be re-hydrated from the old globalState value. Is that acceptable, or should the in-memory update only happen after the persist succeeds?
There was a problem hiding this comment.
Good catch — I changed the ordering so the in-memory viewLocalState update only happens after durable persistence succeeds. The shared helper now awaits persistence first on line 3091, then updates in-memory state on line 3092: ClineProvider.ts.
I also added regression coverage starting on line 847: ClineProvider.parallelMode.spec.ts. The test forces the persisted viewStates write to fail on line 854, verifies saveViewState(...) rejects on line 858, and confirms viewLocalState was not advanced on line 859: ClineProvider.parallelMode.spec.ts.
| this.saveViewState("apiConfiguration", providerSettings), | ||
| ]) | ||
|
|
||
| this._updateViewLocalStateFromMutation({ |
There was a problem hiding this comment.
saveViewState("currentApiConfigName", name) at line 1823 already writes both keys into viewLocalState (line 561). Does _updateViewLocalStateFromMutation here need to repeat that write, or is it a no-op? The setValue/setValues path only calls _updateViewLocalStateFromMutation + _persistViewLocalStateFromMutation without the preceding saveViewState — seems like these two paths could be consolidated.
There was a problem hiding this comment.
Fixed. I consolidated the view-local state update/persist flow so profile activation no longer calls saveViewState(...) and then repeats the same local-state writes through the mutation sync path. Both activateProviderProfile and activated upsertProviderProfile now use the shared mutation helper directly, while setValue / setValues and saveViewState also route through the same helper.
I also added assertions that profile activation does not call saveViewState(...), which catches the duplicate path if it comes back.
| await write | ||
| } | ||
|
|
||
| private async clearPersistedViewState(viewStateId = this.viewStateId): Promise<void> { |
There was a problem hiding this comment.
clearPersistedViewState is defined here but I cannot find any call site for it. When a tab-panel ClineProvider is disposed, its viewStates entry is never cleaned up — it lives until the 50-entry prune evicts it by age. Should this be called from dispose()?
There was a problem hiding this comment.
Yes — fixed. dispose() now clears persisted view-local state for editor/tab providers on line 891: ClineProvider.ts. It is guarded to editor render contexts starting on line 889, so sidebar providers keep their stable persisted state: ClineProvider.ts.
I also added test coverage starting on line 1153: ClineProvider.parallelMode.spec.ts. The test seeds a viewStates entry, disposes the editor provider on line 1160, and verifies the persisted key is removed on line 1162: ClineProvider.parallelMode.spec.ts.
github-actions
Bot
added
awaiting-author
2ef16bb to
37a5dd1
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
src/extension/api.ts (1)
386-411: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winClear
tasksByIdwhen tasks are removed beyond completion/abort.
ClineProvider.dispose()andremoveClineFromStack()remove task instances from the provider registry viaTaskRegistry.remove()without emittingTaskCompleted/TaskAborted, soAPI.tasksByIdcan keep liveRegisteredTaskentries holding strong references toTaskandClineProvider. Clear the API map on task/remove/evict paths, or key the provider cleanup off registry removal.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/extension/api.ts` around lines 386 - 411, The tasksById entries are only deleted on TaskCompleted and TaskAborted, leaving stale strong references when TaskRegistry.remove() is triggered by ClineProvider.dispose() or removeClineFromStack(). Update registerListeners and the relevant provider-removal/eviction flow to delete the task.taskId entry whenever a task is removed without lifecycle completion events, including disposal and stack removal paths.src/core/webview/webviewMessageHandler.ts (1)
1207-1221: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winGuard
kimiCodeOAuthManager.getAccessToken()against rejection.Every other candidate's credential lookup is a plain property read, but this one performs an OAuth token read/refresh. If it throws (expired refresh token, network failure), the whole
requestRouterModelscase rejects beforepostMessageToWebview({ type: "routerModels" })runs, so the model picker stays in a loading state with no error surfaced.🛡️ Proposed fix
if (!providerFilter || providerFilter === "kimi-code") { - const { kimiCodeOAuthManager } = await import("../../integrations/kimi-code/oauth") - const kimiCodeAuthMethod = - message?.values?.kimiCodeAuthMethod ?? apiConfiguration.kimiCodeAuthMethod ?? "oauth" - const kimiCodeApiKey = - kimiCodeAuthMethod === "api-key" - ? (message?.values?.kimiCodeApiKey ?? apiConfiguration.kimiCodeApiKey) - : await kimiCodeOAuthManager.getAccessToken() - if (kimiCodeApiKey) { - candidates.push({ - key: "kimi-code", - options: { provider: "kimi-code", apiKey: kimiCodeApiKey }, - }) + try { + const { kimiCodeOAuthManager } = await import("../../integrations/kimi-code/oauth") + const kimiCodeAuthMethod = + message?.values?.kimiCodeAuthMethod ?? apiConfiguration.kimiCodeAuthMethod ?? "oauth" + const kimiCodeApiKey = + kimiCodeAuthMethod === "api-key" + ? (message?.values?.kimiCodeApiKey ?? apiConfiguration.kimiCodeApiKey) + : await kimiCodeOAuthManager.getAccessToken() + if (kimiCodeApiKey) { + candidates.push({ + key: "kimi-code", + options: { provider: "kimi-code", apiKey: kimiCodeApiKey }, + }) + } + } catch (error) { + provider.log( + `[requestRouterModels] kimi-code credential lookup failed: ${error instanceof Error ? error.message : String(error)}`, + ) } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/core/webview/webviewMessageHandler.ts` around lines 1207 - 1221, Update the kimi-code candidate handling in requestRouterModels to catch rejections from kimiCodeOAuthManager.getAccessToken(), allowing the flow to continue and always reach postMessageToWebview({ type: "routerModels" }). Preserve API-key behavior and only add a candidate when a credential is successfully available.src/core/webview/__tests__/ClineProvider.spec.ts (1)
580-592: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winDon’t leak the
hasLoadedFullDetailsoverride.
mockReturnValue(true)is not restored, and Vitest config only clears call counts/clear mocks here — it will remain mocked for later tests. Reset it in this test (mockReset(true)) or restore/replace it inafterEach.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/core/webview/__tests__/ClineProvider.spec.ts` around lines 580 - 592, Reset the hasLoadedFullDetails mock after this test so its mockReturnValue(true) does not affect later tests. Update the test cleanup or use the mock’s reset/restore behavior while preserving the existing assertion that forceFullModelDetailsLoad is not called.
🧹 Nitpick comments (7)
packages/types/src/api.ts (1)
19-30: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueAdd
preserveOpenTabsto the destructuring list for consistency.The parameter pattern lists
configuration, text, images, newTabbut not the new field, so the declaration no longer mirrors the option type. Type-wise it's inert, but it reads as an omission.♻️ Proposed tweak
startNewTask({ configuration, text, images, newTab, + preserveOpenTabs, }: {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/types/src/api.ts` around lines 19 - 30, Update the startNewTask parameter destructuring to include preserveOpenTabs, keeping it aligned with the accompanying options type while preserving the existing parameter behavior.src/core/webview/webviewMessageHandler.ts (1)
565-582: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winWrap the
webviewDidLaunchcase body in a block.Biome flags
customModes(Line 565) andmcpHub(Line 579) aslint/correctness/noSwitchDeclarations— the bindings leak into sibling clauses (TDZ risk) and this is reported as an error, so lint will fail.♻️ Proposed fix
- case "webviewDidLaunch": + case "webviewDidLaunch": { await provider.setViewStateId(message.viewStateId) @@ provider.isViewLaunched = true break + }The same pattern applies to
vsCodeLmModelsat Line 1372.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/core/webview/webviewMessageHandler.ts` around lines 565 - 582, Wrap the webviewDidLaunch switch case body in braces so its customModes and mcpHub declarations are scoped to that case; apply the same block scoping to the case declaring vsCodeLmModels, without changing their existing logic.Source: Linters/SAST tools
apps/vscode-e2e/src/runTest.ts (1)
136-149: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winThis fixture supersedes the legacy regex fixture below (lines 166-184).
Both match the post-
switch_mode→ask turn and return the sameattempt_completionwith idcall_modes_post_switch_001. Keeping both leaves a dead fixture plus a now-stale explanatory comment; consider removing the/^<environment_details>/one.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/vscode-e2e/src/runTest.ts` around lines 136 - 149, Remove the superseded legacy regex fixture matching the post-switch-to-Ask turn, along with its stale explanatory comment. Keep the newer fixture using toolResultContains for call_modes_switch_001 and its existing attempt_completion response unchanged.apps/vscode-e2e/src/suite/view-state.test.ts (1)
120-120: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value
taskNamesByIdis written but never read.Drop it, or use it in the timeout diagnostics message.
Also applies to: 205-205
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/vscode-e2e/src/suite/view-state.test.ts` at line 120, Remove the unused taskNamesById Map declaration from the affected test flows, unless the timeout diagnostics need task-name context; in that case, use it when constructing the timeout diagnostic message. Apply the same change at both referenced locations.src/core/webview/__tests__/ClineProvider.parallelMode.spec.ts (1)
684-733: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueDuplicate isolation test.
should allow different modes in separate instances after saveViewState(707-733) exercises exactly the same behavior asshould isolate mode state between instances(685-705) — two providers, two distinct modes, same assertions. Consider dropping one.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/core/webview/__tests__/ClineProvider.parallelMode.spec.ts` around lines 684 - 733, Remove the duplicate test case “should allow different modes in separate instances after saveViewState” from the “local state isolation” suite, keeping the existing “should isolate mode state between instances” coverage and its cleanup intact.src/extension/api.ts (1)
355-365: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueSilent no-op when
modeis invalid.
selectTaskFollowupSuggestionstill returnstrueafter ignoring an unknown mode slug, so callers can't distinguish "switched" from "silently skipped". A log line (consistent with the rest of the class) would make this debuggable.♻️ Suggested logging
if (isValidMode) { await entry.provider.handleModeSwitch(mode) + } else { + this.log(`[API#selectTaskFollowupSuggestion] ignoring unknown mode "${mode}" for task ${taskId}`) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/extension/api.ts` around lines 355 - 365, Update selectTaskFollowupSuggestion so the invalid-mode branch logs an appropriate warning or error using the class’s existing logging convention when isValidMode is false, while preserving the current response handling and return value.apps/vscode-e2e/src/fixtures/view-state.ts (1)
3-15: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRound count is duplicated between the fixture module and the suite.
ROUNDSis defined only locally in the fixture module and never validated againstMODE_SEQUENCES, so the suite repeats the literal10; a change in one place silently breaks the other (missing rounds yieldmode: undefinedin fixtures).
apps/vscode-e2e/src/fixtures/view-state.ts#L3-L15: derive/validateROUNDSfromMODE_SEQUENCESlengths and export it.apps/vscode-e2e/src/suite/view-state.test.ts#L209-L242: replace the hardcoded10inplan.length * 10and theroundIndex < 10loop with the exported round count (ortaskPlan.rounds.length).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/vscode-e2e/src/fixtures/view-state.ts` around lines 3 - 15, The fixture and suite duplicate the round count, allowing MODE_SEQUENCES and test iteration counts to diverge. In apps/vscode-e2e/src/fixtures/view-state.ts#L3-L15, derive and validate the exported ROUNDS from MODE_SEQUENCES lengths; in apps/vscode-e2e/src/suite/view-state.test.ts#L209-L242, replace both hardcoded 10 values in plan.length * 10 and the roundIndex loop with the exported ROUNDS or taskPlan.rounds.length.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/vscode-e2e/src/suite/view-state.test.ts`:
- Around line 49-50: Update the first test’s cleanup in its finally block to
unregister the TaskModeSwitched listener as well as completionHandler, using the
listener reference from globalThis.api.on. Mirror the existing cleanup pattern
in the second test so modeEvents is no longer mutated after the test completes.
In `@src/core/webview/ClineProvider.ts`:
- Around line 901-909: Update the editor cleanup in ClineProvider.dispose() so
clearPersistedViewState() runs only for a user-initiated tab close, not VS Code
shutdown, reload, or extension deactivation. Preserve the existing persisted
view state across lifecycle teardown so mode and currentApiConfigName remain
restorable.
---
Outside diff comments:
In `@src/core/webview/__tests__/ClineProvider.spec.ts`:
- Around line 580-592: Reset the hasLoadedFullDetails mock after this test so
its mockReturnValue(true) does not affect later tests. Update the test cleanup
or use the mock’s reset/restore behavior while preserving the existing assertion
that forceFullModelDetailsLoad is not called.
In `@src/core/webview/webviewMessageHandler.ts`:
- Around line 1207-1221: Update the kimi-code candidate handling in
requestRouterModels to catch rejections from
kimiCodeOAuthManager.getAccessToken(), allowing the flow to continue and always
reach postMessageToWebview({ type: "routerModels" }). Preserve API-key behavior
and only add a candidate when a credential is successfully available.
In `@src/extension/api.ts`:
- Around line 386-411: The tasksById entries are only deleted on TaskCompleted
and TaskAborted, leaving stale strong references when TaskRegistry.remove() is
triggered by ClineProvider.dispose() or removeClineFromStack(). Update
registerListeners and the relevant provider-removal/eviction flow to delete the
task.taskId entry whenever a task is removed without lifecycle completion
events, including disposal and stack removal paths.
---
Nitpick comments:
In `@apps/vscode-e2e/src/fixtures/view-state.ts`:
- Around line 3-15: The fixture and suite duplicate the round count, allowing
MODE_SEQUENCES and test iteration counts to diverge. In
apps/vscode-e2e/src/fixtures/view-state.ts#L3-L15, derive and validate the
exported ROUNDS from MODE_SEQUENCES lengths; in
apps/vscode-e2e/src/suite/view-state.test.ts#L209-L242, replace both hardcoded
10 values in plan.length * 10 and the roundIndex loop with the exported ROUNDS
or taskPlan.rounds.length.
In `@apps/vscode-e2e/src/runTest.ts`:
- Around line 136-149: Remove the superseded legacy regex fixture matching the
post-switch-to-Ask turn, along with its stale explanatory comment. Keep the
newer fixture using toolResultContains for call_modes_switch_001 and its
existing attempt_completion response unchanged.
In `@apps/vscode-e2e/src/suite/view-state.test.ts`:
- Line 120: Remove the unused taskNamesById Map declaration from the affected
test flows, unless the timeout diagnostics need task-name context; in that case,
use it when constructing the timeout diagnostic message. Apply the same change
at both referenced locations.
In `@packages/types/src/api.ts`:
- Around line 19-30: Update the startNewTask parameter destructuring to include
preserveOpenTabs, keeping it aligned with the accompanying options type while
preserving the existing parameter behavior.
In `@src/core/webview/__tests__/ClineProvider.parallelMode.spec.ts`:
- Around line 684-733: Remove the duplicate test case “should allow different
modes in separate instances after saveViewState” from the “local state
isolation” suite, keeping the existing “should isolate mode state between
instances” coverage and its cleanup intact.
In `@src/core/webview/webviewMessageHandler.ts`:
- Around line 565-582: Wrap the webviewDidLaunch switch case body in braces so
its customModes and mcpHub declarations are scoped to that case; apply the same
block scoping to the case declaring vsCodeLmModels, without changing their
existing logic.
In `@src/extension/api.ts`:
- Around line 355-365: Update selectTaskFollowupSuggestion so the invalid-mode
branch logs an appropriate warning or error using the class’s existing logging
convention when isValidMode is false, while preserving the current response
handling and return value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 98f52931-0f0a-4b0f-980c-3c91340bce56
📒 Files selected for processing (22)
apps/vscode-e2e/fixtures/modes.jsonapps/vscode-e2e/src/fixtures/view-state.tsapps/vscode-e2e/src/runTest.tsapps/vscode-e2e/src/suite/view-state.test.tspackages/types/src/__tests__/index.test.tspackages/types/src/api.tspackages/types/src/global-settings.tspackages/types/src/vscode-extension-host.tssrc/core/webview/ClineProvider.tssrc/core/webview/__tests__/ClineProvider.parallelMode.spec.tssrc/core/webview/__tests__/ClineProvider.spec.tssrc/core/webview/__tests__/ClineProvider.sticky-mode.spec.tssrc/core/webview/__tests__/webviewMessageHandler.spec.tssrc/core/webview/webviewMessageHandler.tssrc/eslint-suppressions.jsonsrc/extension/__tests__/api-set-configuration.spec.tssrc/extension/__tests__/api-task-control.spec.tssrc/extension/api.tswebview-ui/src/App.tsxwebview-ui/src/__tests__/App.spec.tsxwebview-ui/src/context/ExtensionStateContext.tsxwebview-ui/src/context/__tests__/ExtensionStateContext.spec.tsx
💤 Files with no reviewable changes (1)
- webview-ui/src/App.tsx
| if (this.renderContext === "editor") { | ||
| try { | ||
| await this.clearPersistedViewState() | ||
| } catch (error) { | ||
| this.log( | ||
| `[dispose] Failed to clear persisted view state for ${this.viewStateId}: ${error instanceof Error ? error.message : String(error)}`, | ||
| ) | ||
| } | ||
| } |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect dispose wiring and any deactivate-time disposal of providers.
rg -n --type=ts -C5 'onDidDispose|deactivate\s*\(' src/core/webview/ClineProvider.ts src/extension.ts 2>/dev/null
fd -t f 'extension.ts' src --exec rg -n -C5 'dispose\(\)' {}Repository: Zoo-Code-Org/Zoo-Code
Length of output: 1514
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "===== files ====="
git ls-files 'src/core/webview/ClineProvider.ts' 'src/extension.ts' | sed -n '1,20p'
echo "===== ClineProvider dispose/viewState relevant sections ====="
wc -l src/core/webview/ClineProvider.ts
sed -n '840,925p' src/core/webview/ClineProvider.ts
sed -n '1090,1155p' src/core/webview/ClineProvider.ts
rg -n -C3 'renderContext|viewStateId|clearPersistedViewState|Persisted|getCurrentApiConfig|mode' src/core/webview/ClineProvider.ts
echo "===== extension deactivate relevant section ====="
sed -n '350,395p' src/extension.ts
rg -n -C4 'extensionContext|subscriptions|provider|ClineProvider|activate|deactivate' src/extension.tsRepository: Zoo-Code-Org/Zoo-Code
Length of output: 38485
🌐 Web query:
VS Code WebviewView.onDidDispose extension deactivation webview panel dispose documentations
💡 Result:
In VS Code extensions, the onDidDispose event is the standard mechanism to handle the cleanup of resources associated with a WebviewView or WebviewPanel when it is closed or destroyed [1][2]. Key Concepts and Usage: Event Purpose: The onDidDispose event fires when the webview is destroyed, either by the user closing the panel/view or by the extension programmatically calling dispose() [1][3]. It is essential for preventing memory leaks by allowing you to clean up timers, event listeners, file watchers, and other resources tied to that webview instance [1][4]. Implementation Pattern: You should register the onDidDispose listener within your extension, typically by passing your context.subscriptions to ensure it is managed correctly as the extension deactivates [1][5]. Example using WebviewPanel: panel.onDidDispose( => { // Cleanup resources here, e.g., clear intervals or timeouts clearInterval(interval); }, null, context.subscriptions); WebviewView Considerations: WebviewView instances also provide an onDidDispose event (or onDispose depending on the internal interface) to signal when the view pane is disposed [6][7][2]. Like WebviewPanel, this is the signal to clear associated disposables and state [7][5]. Important Technical Notes: 1. Asynchronous Nature: Communication between the extension host and the webview is asynchronous [8]. While onDidDispose is the correct hook for cleanup, be aware that attempting to access a webview instance immediately after an operation that triggers its disposal may occasionally lead to errors if the internal state has already been marked as disposed [8]. 2. Resource Management: Always use the context.subscriptions array when registering events or disposables to ensure everything is cleaned up when the extension is deactivated or the workbench component is destroyed [1][5]. 3. Manual Disposal: You can programmatically close a webview panel by calling the dispose() method on the panel object itself [1][3]. When you call dispose(), the onDidDispose event will still fire [1][5]. For complex scenarios, such as managing shared resources across multiple editors or views, ensure your cleanup logic is idempotent so that it handles both user-initiated closure and extension-initiated disposal gracefully [4][5].
Citations:
- 1: https://code.visualstudio.com/api/extension-guides/webview
- 2: https://github.com/microsoft/vscode/blob/9d557c62/src/vs/workbench/api/common/extHostWebviewView.ts
- 3: https://github.com/Microsoft/vscode-docs/blob/master/api/extension-guides/webview.md
- 4: https://code.visualstudio.com/api/extension-guides/custom-editors
- 5: https://github.com/microsoft/vscode-extension-samples/blob/main/webview-sample/src/extension.ts
- 6: https://github.com/microsoft/vscode/blob/e8db8ed8/src/vs/workbench/contrib/webviewView/browser/webviewViewService.ts
- 7: https://github.com/microsoft/vscode/blob/99489178/src/vs/workbench/contrib/webviewView/browser/webviewViewPane.ts
- 8: panel.onDidDispose can't reliable be used to avoid exceptions microsoft/vscode#48509
🌐 Web query:
VS Code WorkbenchExtension activation events extension reloading extension deactivation dispose webview persistence state
💡 Result:
Visual Studio Code extensions use a lazy-loading architecture governed by activation events, a well-defined lifecycle, and specific patterns for resource disposal and state persistence. Activation Events Extensions remain inactive until a specific trigger occurs. You must declare these in the activationEvents field of your package.json [1][2]. Common events include onLanguage (file opened), onCommand (command invoked), and workspaceContains (file exists in workspace) [1][2]. Note that as of VS Code 1.74.0, commands declared in the commands contribution section automatically trigger activation without requiring an explicit onCommand entry [3][4]. Extension Lifecycle The extension entry point typically exports two functions: activate and deactivate [3][4]. 1. activate: Called when the registered activation event occurs. This is where you initialize your extension and register commands, providers, and subscriptions [3][5]. 2. deactivate: Optional. Use this to perform explicit cleanup, such as closing external handles or deleting temporary files when the extension is disabled, uninstalled, or VS Code shuts down [3][4]. For most extensions, this is not needed if you properly use the context.subscriptions array [5]. Dispose and Resource Management The most important practice for lifecycle management is pushing disposables (e.g., event listeners, command registrations) into the context.subscriptions array provided in the activate function [5]. VS Code automatically calls.dispose on all items in this array when the extension is deactivated, ensuring clean resource management [5]. Webview Persistence and State Webview panels are destroyed when closed or disposed, but their contents are also destroyed if the panel is moved to the background [6][7]. To handle this: 1. getState/setState: Scripts inside the webview can use these methods to save and restore JSON-serializable state [6][7]. This is the preferred, high-performance method [6][7]. 2. WebviewPanelSerializer: To restore webviews after a VS Code restart, you must register a WebviewPanelSerializer in your activate function. It uses the state saved via setState to reconstruct the panel [6][7][8]. 3. retainContextWhenHidden: For complex UIs that cannot be easily serialized, you can set this property to true. It keeps the webview content alive in a hidden state, though it consumes more resources [6][7]. Extension Reloading VS Code does not natively support "hot reloading" of extension code while the host is running [9][10]. To reload an extension during development, you must reload the VS Code window (e.g., via the Developer: Reload Window command) [10]. Some developers implement file system watchers to trigger this command automatically when source files change [10].
Citations:
- 1: https://code.visualstudio.com/api/references/activation-events
- 2: https://vscode-docs.readthedocs.io/en/stable/extensionAPI/activation-events/
- 3: https://code.visualstudio.com/api/get-started/extension-anatomy
- 4: https://github.com/microsoft/vscode-docs/blob/538f9c60/api/get-started/extension-anatomy.md
- 5: https://deepwiki.com/microsoft/vscode-extension-samples/2.1-extension-lifecycle-and-activation
- 6: https://code.visualstudio.com/api/extension-guides/webview
- 7: https://github.com/Microsoft/vscode-docs/blob/master/api/extension-guides/webview.md
- 8: https://github.com/microsoft/vscode-extension-samples/blob/main/webview-sample/src/extension.ts
- 9: Allow reloading changes in workspace extensions microsoft/vscode#208698
- 10: https://stackoverflow.com/questions/75305144/how-to-restart-reload-vs-code-host-window-on-extension-source-code-file-changes
Avoid clearing editor-tab persisted state on every dispose().
onDidDispose is also reached when VS Code shuts down, reloads, or the extension is deactivated, and dispose() currently unconditionally deletes viewStates[viewStateId] for renderContext === "editor". This drops the restored tab’s mode/currentApiConfigName; gate this cleanup to user-initiated tab close or otherwise preserve VS Code-persisted view state for restarts.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/core/webview/ClineProvider.ts` around lines 901 - 909, Update the editor
cleanup in ClineProvider.dispose() so clearPersistedViewState() runs only for a
user-initiated tab close, not VS Code shutdown, reload, or extension
deactivation. Preserve the existing persisted view state across lifecycle
teardown so mode and currentApiConfigName remain restorable.
There was a problem hiding this comment.
@coderabbitai onDidDispose does not reliably distinguish user tab close from reload/shutdown/deactivation.
please provide a plan to fix. this should be fix in another pr.
There was a problem hiding this comment.
@easonLiangWorldedtech Agreed — disposal is not a reliable lifecycle discriminator, so the cleanup must not infer intent from onDidDispose.
Follow-up PR plan: preserve view state unless a tab is explicitly closed
- Introduce an explicit “close this view state” flow, initiated by the webview while it is still alive (for example, a dedicated close command/message or an intentional UI action).
- In
src/core/webview/webviewMessageHandler.tsandsrc/core/webview/ClineProvider.ts, validate that close intent belongs to the currentviewStateId, then remove only thatviewStates[viewStateId]entry. - Remove
clearPersistedViewState()from the genericClineProvider.dispose()path. Disposal should only release runtime resources; it must preserve durable state during reload, shutdown, extension deactivation, and restoration. - Keep the existing bounded persistence behavior (50 most-recent entries), so tabs closed without an explicit signal are eventually eligible for timestamp-based eviction rather than immediately losing state.
- Add focused tests covering:
- explicit tab-close intent removes the corresponding persisted entry;
dispose()without close intent preserves state;- reload/deactivation-style disposal restores the same mode and API-profile selection;
- a close signal from one tab cannot remove another tab’s entry;
- no profile configuration or secrets are persisted/introduced by the new flow.
Would you like me to open a GitHub follow-up issue for this plan and assign it to you?
✏️ Learnings added
Learnt from: easonLiangWorldedtech
Repo: Zoo-Code-Org/Zoo-Code PR: 977
File: src/core/webview/ClineProvider.ts:0-0
Timestamp: 2026-07-30T20:04:05.204Z
Learning: For `src/core/webview/ClineProvider.ts`, VS Code `onDidDispose` does not reliably distinguish an explicit user tab close from reload, shutdown, or extension deactivation. Do not use generic provider disposal as the signal to delete durable per-view `viewStates`; explicit close intent is required.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
Failed to handle agent chat message. Please try again.
You are interacting with an AI system.
There was a problem hiding this comment.
@coderabbitai please create issue and point out the way out suggestions
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
repo="Zoo-Code-Org/Zoo-Code"
body=$(cat <<'EOF'
## Summary
Follow up on the durable per-view state work from `#977`: `ClineProvider.dispose()` must not delete an editor tab's persisted `viewStates[viewStateId]` entry merely because the provider is being disposed.
`onDidDispose` / provider disposal does not reliably identify an explicit user tab close. It can also occur during VS Code reload, shutdown, or extension deactivation, where the persisted mode and selected API profile must remain available for restoration.
Requested by: `@easonLiangWorldedtech`
## Required changes
- Remove `clearPersistedViewState()` from the generic `ClineProvider.dispose()` lifecycle path.
- Make disposal runtime-resource cleanup only; retain durable per-view state by default.
- If immediate deletion for an explicitly closed tab is still desired, implement it through a separate, explicit lifecycle signal that is not inferred from `onDidDispose`.
- Preserve the existing cap of 50 most-recent persisted entries and timestamp-based pruning.
## Suggested approaches
1. **Recommended: retention-only**
- Do not delete state on close.
- Rely on the existing 50-entry timestamp-based pruning to bound storage.
- This is the simplest and safest approach because it preserves restart/reload restoration without needing an unreliable close discriminator.
2. **Explicit close protocol**
- Add a narrowly scoped command or message that records explicit close intent while the webview is alive.
- Validate that the intent applies only to the current `viewStateId`, then remove that one entry.
- Keep generic disposal non-destructive as a fallback, since the close signal may be unavailable during host teardown.
3. **Lifecycle-aware cleanup (only if VS Code exposes a reliable signal)**
- Investigate whether the tab creation/management path has a close-specific signal distinct from host reload/deactivation.
- Use it only if it is demonstrably reliable across reload/shutdown/deactivation; otherwise prefer approach 1 or 2.
## Affected areas
- `src/core/webview/ClineProvider.ts`
- Potentially `src/core/webview/webviewMessageHandler.ts` and the webview state/message types if an explicit close protocol is selected.
- Focused unit tests for per-view persistence and disposal behavior.
## Acceptance criteria
- Calling `ClineProvider.dispose()` without explicit close intent leaves `viewStates[viewStateId]` intact.
- Reload/deactivation-style teardown restores the same persisted `mode` and `currentApiConfigName`.
- Any explicit cleanup removes only the intended view-state entry and cannot remove another tab's entry.
- Persisted view state continues to contain only non-secret fields (`mode`, `currentApiConfigName`, `updatedAt`).
- The 50-entry maximum and newest-first pruning behavior remain intact.
## Backlinks
- PR: https://github.com/Zoo-Code-Org/Zoo-Code/pull/977
- Review discussion: https://github.com/Zoo-Code-Org/Zoo-Code/pull/977#discussion_r3684795957
EOF
)
gh issue create \
--repo "$repo" \
--title "Preserve durable editor view state across provider disposal" \
--body "$body" \
--assignee "easonLiangWorldedtech"Length of output: 3382
@easonLiangWorldedtech, confirmed: the follow-up issue was created and assigned to you:
#1065 — Preserve durable editor view state across provider disposal
#1065
Correction: my prior reply listed the wrong issue number. The correct issue is #1065.
You are interacting with an AI system.
|
Added Summary:
Validation:
Note: I intentionally kept the persisted view-state fix minimal. Since |
|
Follow-up plan for the e2e coverage requested here: I created PR #1064 as the first dedicated e2e foundation PR for this work: The intent is to keep #977 focused on the durable per-view state base, while using follow-up PRs to build progressively heavier real VS Code e2e coverage on top of it. PR #1064 establishes reusable orchestrator fixtures, delegation lifecycle coverage, resource diagnostics, and cleanup/convergence checks that future parallel-mode e2e tests can reuse. Planned e2e levels: Level 1: view state + orchestrator across 3 tabsUse three real tab/sidebar providers and verify that each panel keeps isolated view-local state while orchestrator tasks delegate and resume independently. This should cover:
Level 2: view state + orchestrator + follow-up option mode switching across tabsExtend Level 1 by using real This should cover:
Level 3: reload / restoration stressAfter Level 1 and Level 2 prove live isolation, the next important boundary is persistence across lifecycle events. Suggested scenario:
This directly protects the durable per-view state mechanism introduced by #977. Level 4: interrupted child / recovery across panelsStress delegation state and view state together. Suggested scenario:
This catches the class of bugs where task lifecycle state and provider-local view state accidentally share the wrong boundary. Final boss: mixed parallel orchestration with reload, recovery, and resource convergenceA final high-value e2e could combine the important boundaries into one long-running smoke/stress scenario:
That would be the “final boss” parallel-mode e2e: real VS Code host, multiple live providers, real globalState boundary, view-local state isolation, orchestrator delegation, follow-up mode switching, cancellation/recovery, and resource leak detection in one scenario. I do not think all of this should block #977. My proposal is:
|
5054111 to
97afc41
Compare
|
rebased |
github-actions
Bot
added
awaiting-review
3 participants
Summary
Add the foundational per-view state infrastructure for parallel mode. This is the root PR that all subsequent parallel-mode PRs depend on.
Addresses old Issue #908 (root mechanism). Fixes persistence limitation by introducing registered global
viewStateswith bounded cleanup and proper ContextProxy hydration.Changes
webview_state_idviewLocalStatebuffer: Transient per-view state that merges with global state viagetState()layerviewStatespersistence: Registered global setting key storing only non-secret selections (mode,currentApiConfigName,updatedAt) — bounded to most recent 50 entriesKey Design Decisions
Durable per-view persistence via registered global
viewStatesPreviously, persistence relied on scattered dynamic
__view_state_*keys that were not formally registered. Now:viewStatesis a formal entry inglobalSettingsSchemaand included inGLOBAL_STATE_KEYSContextProxy.initialize()on startup, then hydrated throughloadViewState()which resolves profile settings viaProviderSettingsManager.getProfile()modeandcurrentApiConfigName. FullapiConfiguration(including API keys/secrets) is NOT stored in globalState.Tests
Related
Summary by CodeRabbit
New Features
viewStatessetting, including isolated mode and API profile selection byviewStateId.preserveOpenTabssupport for new tasks.Bug Fixes
Tests