Fix mode state sharing when switching between open vscode windows #1569
Conversation
|
dosubot
bot
added
size:L
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
src/core/contextProxy.ts
Outdated
| const value = this.stateCache.get(key) as T | undefined | ||
| return value !== undefined ? value : (defaultValue as T | undefined) | ||
| // Check for window-specific key | ||
| if (this.isWindowSpecificKey(key)) { |
There was a problem hiding this comment.
Both branches in getGlobalState use identical cache access logic. Consider simplifying to a single branch to improve clarity.
src/core/contextProxy.ts
Outdated
| } | ||
| } | ||
|
|
||
| updateGlobalState<T>(key: string, value: T): Thenable<void> { |
There was a problem hiding this comment.
If the asynchronous update in updateGlobalState fails, the in-memory cache remains updated, potentially causing an inconsistent state. Consider adding error handling to reconcile or revert the cache update on failure.
| const windowKey = this.getWindowSpecificKey(key) | ||
| const value = this.originalContext.globalState.get(windowKey) | ||
| this.stateCache.set(key, value) |
There was a problem hiding this comment.
- This code will make roo save nothing, and make vscode.ExtensionContext wasted
- can you have reproduce of the bug (if you have video is perfect) when share mode between window ?
There was a problem hiding this comment.
i think you just skip save and get this.originalContext.globalState when it "this.isWindowSpecificKey"
There was a problem hiding this comment.
Hi, thanks for your time on this.
I appreciate your input (I am NOT a TypeScript or vscode plugin developer) so tried to fix this myself and see if it was viable with you guys.
Clearly I've missed some knock on effects here so will investigate and double-check prior to any more.
Also this is my first PR ever (in 25 years of application building - we don't work with github for our data operations) so I realise I should have drafted it first, resolved autobot feedback, re-reviewed and then submitted. I will next time.
As for the video..I honestly cannot believe it. I cannot reliably reproduce it. It has bugged me for weeks and weeks now (literally switch one mode and the other would switch at the next message break/send). My update fixed it for me, stopped immediately for the last couple of days.
I usually have 3-6 windows open, each with different projects, each using Roo-Code and flick each one in and out of devcontainers frequently. Perhaps there is something in the sequence that I am not catching.
I will record it's next occurrence and share but this PR is probably dead without reproducible evidence.
Meanwhile..I have another fix for a task history issue (will check issues first) but clicking recent tasks to restore them deletes them if you create them in/out of a devcontainer and then try to open from the opposite place (out/in). Easily done by accident and trashes them which is shame. May suggest to popup a message but leave the entry in-place, or optionally, configure to store task history on a per project-basis on disk (configurable location). Then you can view, restore, resume, analyse etc.. One to think about.
Cheers,
Iain
There was a problem hiding this comment.
@antsbuildit The mode switching state was an issue but we released a fix last Friday (3.8)
…ExtensionContext wasted)
4 participants
Fix mode state sharing when switching between open vscode windows
Context
When using Roo-Code in multiple VS Code windows simultaneously, the "mode" setting (Debug, Architect, Code, etc.) was being shared across all windows. This caused a poor user experience as switching modes in one window would unexpectedly change the mode in all other open windows.. For example one vscode project could be in Architect mode, working away on auto and then, due to another vscode window switching to Code mode, the first also does and it changes it's behavior. Annoying when working on multiple projects concurrently using Auto-approve in particular.
Implementation
The root issue was that VS Code's extension
globalStateAPI stores data at the user level rather than per-window. To solve this:Modified the
ContextProxyclass to support window-specific state:windowIdproperty that generates a unique identifier for each window based on workspace pathsWINDOW_SPECIFIC_KEYSarray that defines which settings should be window-specific (currently just 'mode')The implementation is designed to be flexible for future extension:
WINDOW_SPECIFIC_KEYSarraybefore - Changing mode in window 1 changes mode in window 2 (and 3 and 4..) when the next message is submitted
after - Each window maintains its own mode independently
How to Test
Important
Fixes mode state sharing across VS Code windows by implementing window-specific state management in
ContextProxy.ContextProxynow supports window-specific state for 'mode' usingWINDOW_SPECIFIC_KEYS.windowIdinContextProxyto uniquely identify VS Code windows.getGlobalState()andupdateGlobalState()to handle window-specific keys.resetAllState()now resets window-specific keys usingwindowId.generateWindowId()andcreateSessionHash()for unique window identification.initializeStateCache()andinitializeSecretCache()updated for window-specific handling.contextProxy.test.tsupdated to test window-specific state management.generateWindowId()andcreateSessionHash()added to ensure unique ID generation.This description was created by
for b818f6b. It will automatically update as commits are pushed.