jiebi/CodeConvo huggingface dataset:
Code change:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

Related discussion:
text: import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IShellLaunchConfig, TerminalExitReason, TerminalLocation, TerminalSettingId } from 'vs/platform/terminal/common/terminal'; import { IEditorGroup } from 'vs/workbench/services/editor/common/editorGroupsService'; <del> import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; </del> <ins> import { ILifecycleService, ShutdownReason, WillShutdownEvent } from 'vs/workbench/services/lifecycle/common/lifecycle'; </ins> import { ConfirmOnKill } from 'vs/workbench/contrib/terminal/common/terminal'; import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration';
Code change:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

Related discussion:
text: // Don't dispose editor when instance is torn down on shutdown to avoid extra work and so // the editor/tabs don't disappear <del> this._lifecycleService.onWillShutdown(() => { </del> <ins> this._lifecycleService.onWillShutdown((e: WillShutdownEvent) => { </ins> this._isShuttingDown = true; dispose(disposeListeners); <ins> // Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configurationService.getValue<boolean>(TerminalSettingId.EnablePersistentSessions) && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } else { instance.dispose(TerminalExitReason.Shutdown); } </ins> }); }
Code change:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

Related discussion:
text: readonly _processManager: ITerminalProcessManager; private readonly _resource: URI; <del> private _shutdownPersistentProcessId: number | undefined; </del> // Enables disposal of the xterm onKey // event when the CwdDetection capability // is added
Code change:
Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders

Related discussion:
text: // Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configHelper.config.enablePersistentSessions && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { <del> for (const instance of this.instances) { </del> <ins> for (const instance of this._terminalGroupService.instances) { </ins> instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } return; } <del> // Force dispose of all terminal instances const shouldPersistTerminalsForEvent = this._shouldReviveProcesses(e.reason); for (const instance of this.instances) { if (shouldPersistTerminalsForEvent) { instance.shutdownPersistentProcessId = instance.persistentProcessId; } </del> <ins> // Force dispose of all pane terminal instances for (const instance of this._terminalGroupService.instances) { </ins> instance.dispose(TerminalExitReason.Shutdown); }
Code change:
a change to the file and save, do not commit the diff view from the SCM view up and down in the notebook diff view :cheese: see cell metadata area skittering on screen (the recording below does not capture how frequently the skittering actually happens) https://user-
Just ran into this again: https://user-
I opened for that, I think we can actually just reopen this one
This issue should be gone now since we fixed the horizontal bar issue.

Related discussion:
text: this._editorContainer.style.height = `${editorHeight}px`; this._register(this._editor.onDidContentSizeChange((e) => { <ins> if (this._editorLayoutInProgress) { return; } </ins> if (e.contentHeightChanged && this.cell.layoutInfo.editorHeight !== e.contentHeight) { this.cell.editorHeight = e.contentHeight; }
Code change:
a change to the file and save, do not commit the diff view from the SCM view up and down in the notebook diff view :cheese: see cell metadata area skittering on screen (the recording below does not capture how frequently the skittering actually happens) https://user-
Just ran into this again: https://user-
I opened for that, I think we can actually just reopen this one
This issue should be gone now since we fixed the horizontal bar issue.

Related discussion:
text: const editorViewState = this.cell.getSourceEditorViewState() as editorCommon.IDiffEditorViewState | null; if (editorViewState) { <del> console.log('restore view state', this.cell.modified.handle, editorViewState); </del> this._editor!.restoreViewState(editorViewState); }
Code change:
a change to the file and save, do not commit the diff view from the SCM view up and down in the notebook diff view :cheese: see cell metadata area skittering on screen (the recording below does not capture how frequently the skittering actually happens) https://user-
Just ran into this again: https://user-
I opened for that, I think we can actually just reopen this one
This issue should be gone now since we fixed the horizontal bar issue.

Related discussion:
text: this.cell.editorHeight = contentHeight; } <ins> private _editorLayoutInProgress = false; </ins> layout(state: IDiffElementLayoutState) { DOM.scheduleAtNextAnimationFrame(() => { <ins> this._editorLayoutInProgress = true; </ins> if (state.editorHeight) { this._editorContainer.style.height = `${this.cell.layoutInfo.editorHeight}px`; this._editor!.layout({
Code change:
a change to the file and save, do not commit the diff view from the SCM view up and down in the notebook diff view :cheese: see cell metadata area skittering on screen (the recording below does not capture how frequently the skittering actually happens) https://user-
Just ran into this again: https://user-
I opened for that, I think we can actually just reopen this one
This issue should be gone now since we fixed the horizontal bar issue.

Related discussion:
text: } <ins> this._editorLayoutInProgress = false; </ins> this.layoutNotebookCell(); }); }
Code change:
re The automatic perf monitoring has shown a high number of calls to . This means the call/function itself is slow or it is called at a very high rate (so that the profiler always sees it running) The most common stacktrace via which this is reported comes through .
/duplicate
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I don't think this is a dupe because the callstack comes in via which I don't see in the other trace
But I think the root cause is same for both that is slow as mentioned in the summary of the other issue. Hence I marked it as duplicate.
Pfff - that would mean it is catastrophically slow. My suspicion is that it is just slow but that comes in combination with being over eagerly called? Maybe some event leakage or some over eager calling through some other means. This symptom might disappear when has become fast but I think we need to understand why it ends up on a hot code path in the first place
Will investigate why this is being eagerly called too.

Related discussion:
text: const workbenchRegistry = Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench); workbenchRegistry.registerWorkbenchContribution(ExtensionsContributions, LifecyclePhase.Restored); <del> workbenchRegistry.registerWorkbenchContribution(StatusUpdater, LifecyclePhase.Restored); </del> <ins> workbenchRegistry.registerWorkbenchContribution(StatusUpdater, LifecyclePhase.Eventually); </ins> workbenchRegistry.registerWorkbenchContribution(MaliciousExtensionChecker, LifecyclePhase.Eventually); workbenchRegistry.registerWorkbenchContribution(KeymapExtensions, LifecyclePhase.Restored); workbenchRegistry.registerWorkbenchContribution(ExtensionsViewletViewsContribution, LifecyclePhase.Restored);
Code change:
re The automatic perf monitoring has shown a high number of calls to . This means the call/function itself is slow or it is called at a very high rate (so that the profiler always sees it running) The most common stacktrace via which this is reported comes through .
/duplicate
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I don't think this is a dupe because the callstack comes in via which I don't see in the other trace
But I think the root cause is same for both that is slow as mentioned in the summary of the other issue. Hence I marked it as duplicate.
Pfff - that would mean it is catastrophically slow. My suspicion is that it is just slow but that comes in combination with being over eagerly called? Maybe some event leakage or some over eager calling through some other means. This symptom might disappear when has become fast but I think we need to understand why it ends up on a hot code path in the first place
Will investigate why this is being eagerly called too.

Related discussion:
text: @IWorkbenchExtensionEnablementService private readonly extensionEnablementService: IWorkbenchExtensionEnablementService ) { super(); <ins> this.onServiceChange(); </ins> this._register(Event.debounce(extensionsWorkbenchService.onChange, () => undefined, 100, undefined, undefined, this._store)(this.onServiceChange, this)); }
Code change:
re The automatic perf monitoring has shown a high number of calls to . This means the call/function itself is slow or it is called at a very high rate (so that the profiler always sees it running) The most common stacktrace via which this is reported comes through .
/duplicate
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I don't think this is a dupe because the callstack comes in via which I don't see in the other trace
But I think the root cause is same for both that is slow as mentioned in the summary of the other issue. Hence I marked it as duplicate.
Pfff - that would mean it is catastrophically slow. My suspicion is that it is just slow but that comes in combination with being over eagerly called? Maybe some event leakage or some over eager calling through some other means. This symptom might disappear when has become fast but I think we need to understand why it ends up on a hot code path in the first place
Will investigate why this is being eagerly called too.

Related discussion:
text: this._register(this.storageService.onDidChangeValue(e => this.onDidChangeStorage(e))); } private _reportTelemetry() { const extensionIds = this.installed.filter(extension => !extension.isBuiltin &&
Code change:
start the GH auth flow from window1 focus window2. This step is not necessary if you use multiple screens and the browser is on the same screen as window2. But because I couldn't easily record both screens I manually focus here. continue the GH auth flow in the browser the flow returns to window2 instead of the originating window I grabbed the URL and it has a windowId in it: But perhaps the windowId gets lost somewhere along the way or perhaps there is a bug on the main process. Anyways, here is the recording: https://user-
Alex and I talked about this and based on what I'm seeing, I don't think it's an auth issue and seems to be a Uri Handler issue. If it was an auth bug, I would expect the to be missing from the URL but that doesn't seem to be the case here.
logging revealed something that I then was able to verify in code: the change in changed the kind. When previously a was passed, now it is a . So the code here needs to be adjusted: I think the code could get some type love and not use for that matter. The full value I get logging in the router is:
Hm, I am actually not a 100% sure if that commit caused the regression because I also see you changed the receiving end, but the problem is still the of and being passed in when previously it was just the
Great catch, that's exactly right! I did not adopt the serialization format in the router. I'm open to suggestions, though I'm not sure there is anything that can be done here. The whole point of these implementations is to (de)serialize live objects into opaque JSON things. You can add a bunch of interfaces that lock things in, but in the end we still need the generic and methods, so I'm not sure we'd gain anything.
Basically what  does by avoiding having to code out the underlying raw methods of the IPC flow and have just a typed interface for both sender and receiver. Yes, in the end you cannot know for sure what data is sent because we cannot enforce it, but (or something similar) at least allows to only have 1 place for types and when changing something, it would show an error on both ends.
How would you adopt that in the router?
So I've never been able to repro this bug... are there some steps that really focus on this fix?

Related discussion:
text: throw new Error(`Call not found: ${command}`); } <del> if (arg) { const uri = URI.revive(arg); </del> <ins> if (Array.isArray(arg) && arg.length > 0) { const uri = URI.revive(arg[0]); </ins> this.logService.trace('URLHandlerRouter#routeCall() with URI argument', uri.toString(true));
Code change:
Yesterday I ran VS Code Insiders from the Downloads folder, and I used . And today, after updating to latest Insiders I had to log in again. Here's what I noticed in one of the logs: I often also use which downloads various versions of VS Code Insiders and uses a custom user data dir. Often I end up being signed out . cc
I have seen this error before and I had a time when I had to log in all the time, but not for a while anymore.
Now again I hit this almost daily that I have to re-login.
After 1on1, learned that this is caused simply by launching VS Code from a different path. A suggested fix is to not destroy existing credentials on startup when we fail to decrypt but only do so when we actually need to write new credentials to the store.
What are some verif steps? I'm a little confused on what you mean by "launching VS Code from a different path".
verification: Launch VS Code insiders, make sure you're logged in to something Close VS Code Insiders Open a terminal (not in VS Code Insiders) and run (This will spin up old insiders builds): Note that you are not logged in to anything (expected) in the terminal say or doesn't matter Now once is done open your VS Code Insiders You should still be logged in to your stuff

Related discussion:
text: return value.content; } } catch (parseError) { <ins> // We may not be able to parse it, but we keep the secret in the keychain anyway just in case // it decrypts correctly in the future. </ins> this.logService.error(parseError); <del> // If we can't parse the decrypted value, then it's not a valid secret so we should try to delete it try { await this.credentialsService.deletePassword(fullKey, key); } catch (e) { this.logService.error(e); } </del> throw new Error('Unable to parse decrypted password'); } }