jiebi/CodeConvo huggingface dataset:
Code change:
this._terminalCreationQueue = this._terminalCreationQueue.then(() => this._doCreateTerminal(task, group, launchConfigs!)); const terminal: ITerminalInstance = (await this._terminalCreationQueue)!; <del> terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; </del> <ins> if (task.configurationProperties.isBackground) { terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; } </ins> const terminalKey = terminal.instanceId.toString(); const terminalData = { terminal: terminal, lastTask: taskKey, group }; terminal.onDisposed(() => this._deleteTaskAndTerminal(terminal, terminalData));

Related discussion:
text: There does appear to be a pretty serious bug in that code: It adds to the at line 1839, then starts the task at line 1853, and then removes at line 1855 without waiting for the task to finish. So in practice the list is almost always empty, and doesn't actually do anything. I think the at line 1855 should actually be in a clause attached to the on line 1856, so that it doesn't run until the task completes. But fixing that doesn't actually fix this issue, because the set isn't preserved (or reconstructed) across reloads. In addition it breaks the above behavior where trying to run an already running task asks what you want to do with it (because now that inProgressTasks is actually working, it aborts the attempt to re-run the task before it gets to the point where that dialog is presented). It also breaks tasks that are explicitly marked as allowing more than one instance. So since it isn't currently doing anything, and fixing it breaks things, I would suggest removing all the associated code ( I'm not sure what the actual fix should be though. There seems to be code to try to reconnect tasks to terminals: but it doesn't seem to work (I've stepped through the code with my example, and it goes into but doesn't actually find any tasks to reconnect). So maybe the bug is there. Or maybe the bug is that the tasks shouldn't be preserved across reload (many are not; a terminal that isn't running anything will be killed by reload, for example). But I've reached the limits of what I can debug, unless anyone has suggestions for where to look.
thanks for looking into this. the reason it's not in a is this was meant to (and did) fix an issue that was super hard to reproduce where duplicate tasks would get started. the only tasks that get reconnected to are those with and have problem matchers. you can disable this with .
task reconnection works for me https://user-
Ok. So there's a race that happens between deciding to launch the task and actually launching it? In that case, the solution seems kind of misleading. Shouldn't it be something like rather than ? but also, instead of why not just do And why do you need the in since it was already deleted right after it launched?
Code change:
this._terminalCreationQueue = this._terminalCreationQueue.then(() => this._doCreateTerminal(task, group, launchConfigs!)); const terminal: ITerminalInstance = (await this._terminalCreationQueue)!; <del> terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; </del> <ins> if (task.configurationProperties.isBackground) { terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; } </ins> const terminalKey = terminal.instanceId.toString(); const terminalData = { terminal: terminal, lastTask: taskKey, group }; terminal.onDisposed(() => this._deleteTaskAndTerminal(terminal, terminalData));

Related discussion:
text: But all this is incidental; I was hoping this code could prevent the bug I reported, but clearly it can't.
Ok... but the problem is that my task is left running across the reload, but it doesn't get reconnected (apparently intentionally), so attempting to start it again succeeds, even though it's supposed to only allow one instance. https://user- I'm not sure what that .mov is supposed to be showing me; I can't see anything relating to tasks being reconnected (but I'm not sure what Im looking for). But anyway, I'm not claiming it's broken; just that it doesn't reconnect my task (or similar ones). And if, as you say, thats intentional, then the bug is elsewhere. But as far as I can tell, either my task shouldn't be left running, or it should be reconnected.
Another data point. After reloading, the task is clearly running, but tells me "No running tasks"
So when I set this to false, my task is killed on window reload, which does mitigate the problem (in fact, for my use case, I think this does solve the problem - although I don't know yet whether it introduces new ones). But that still leaves us with the issue when is . The task is left running, but not (properly) reconnected - so although it's there, and its output is going to.a terminal, the abstractTaskService, and terminalTaskSystem aren't aware of it (so that "Show Running Tasks" says there are none, and attempting to start a second instance succeeds).
I won't be looking into this any time soon just fyi. So if it bothers you, feel free to keep digging. Otherwise, just keep the setting disabled.
I run into this problem all the time too, which is very frustrating. I have to reload often due to SSH reconnection etc, this reattach issue together with ssh agent forwarding on mac os breaking, are really detrimental to the work flow. Using works around some of the issue, but exposes a new one; one of my processes doesn't get killed and blocks the new one from starting. That process appears to be a nodemon process, perhaps related to
Yeah that is unrelated to this feature as you mentioned.
as noted in the pull request, this doesn't fix everything, but it makes my workflow (with several auto-run tasks) much cleaner.
Code change:
this._terminalCreationQueue = this._terminalCreationQueue.then(() => this._doCreateTerminal(task, group, launchConfigs!)); const terminal: ITerminalInstance = (await this._terminalCreationQueue)!; <del> terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; </del> <ins> if (task.configurationProperties.isBackground) { terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; } </ins> const terminalKey = terminal.instanceId.toString(); const terminalData = { terminal: terminal, lastTask: taskKey, group }; terminal.onDisposed(() => this._deleteTaskAndTerminal(terminal, terminalData));

Related discussion:
text: Those tasks will be properly reconnected on reload, rather than an additional set being kicked off on each reload. For tasks that don't auto-run on reload, the only change is that the first attempt to run a new instance of that task will simply attach to the existing process; and subsequent attempts will fail the same way they do before the reload. Other than that, there should be no change in behavior, so I think this should be pretty safe. I spent some time trying to figure out how to actually reconnect all the running tasks, rather than just marking them for reconnection, but I kept running into issues where needed to know about the internals of ( in particular). Or I needed to extend the ITaskSystem api - which I'm reluctant to do without guidance. I also tried a completely different approach - namely, including non-background tasks in . That almost worked, but the problem was that gave a different result when the task is launched manually vs when it's run from (when run manually, its a , but when run from its a , which gets resolved to a ). As a result, the tasks did get reconnected properly, the various commands (eg ) know they're there and do the right thing; but now trying to run them manually uses a different key, and still starts a new copy...
thanks for looking into this. I commented on your PR
To verify, run a non background task. Reload the window. Verify that you can run that task again
Code change:
group: '', title: nls.localize('actions.clipboard.copyLabel', "Copy"), order: 1 <ins> }, { menuId: MenuId.SimpleEditorContext, group: CLIPBOARD_CONTEXT_MENU_GROUP, title: nls.localize('actions.clipboard.copyLabel', "Copy"), order: 2, </ins> }] })) : undefined;

Related discussion:
text: re focus SCM input show context menu the is a entry "Command Palette..." which is awkward <img width="703" alt="image" src="https://user-"
Related to this, on my system that context menu also gives me entries that have been contributed by a couple of my extensions.
Same issue on macOS as well
This happens across all our inputs which use the Editor. IMO we should not include all those contributions and should just have , & in that menu. What's the simplest way towards this
The "Command Palette..." should potentially have a better context key for , not :
Thanks! But this is actually only half of the story. As mentions, extension contributed commands show up: ! Should we file issues to these extensions, suggesting to change their clauses?
It might be better/simpler to have another menu id, something like or even something SCM specific
To reproduce, you can use:
Code change:
private getMarkersItemTurnedOff(): IStatusbarEntry { const config = this.configurationService.getValue('problems.visibility'); <del> if (config) { return { name: '', text: '', ariaLabel: '', tooltip: '', command: '' }; } </del> <ins> this.statusbarService.updateEntryVisibility('status.problemsVisibility', !config); </ins> const openSettingsCommand = 'workbench.action.openSettings'; <del> const configureSettingsLabel = 'problems.visibility'; </del> <ins> const configureSettingsLabel = '@id:problems.visibility'; </ins> const tooltip = !config ? localize('problemsOff', "Problems have been turned off.") : ''; return { <del> name: localize('status.problems.off', "Problems"), </del> <ins> name: localize('status.problemsVisibility', "Problems Visibility"), </ins> text: '$(whole-word)', ariaLabel: tooltip, tooltip,

Related discussion:
text: Testing Why is the setting name linked once and once it just shows the ID? Both should be linked, or maybe you can rephrase it to just use the setting name once like <img width="548" alt="image" src=""
That's a good point yeah
Code change:
} public validate(): boolean { <del> let result: IMessage = null; </del> <ins> let errorMsg: IMessage = null; </ins> if (this.validation) { <del> result = this.validation(this.value); </del> <ins> errorMsg = this.validation(this.value); </ins> <del> if (!result) { </del> <ins> if (errorMsg) { this.inputElement.setAttribute('aria-invalid', 'true'); this.showMessage(errorMsg); } else if (this.inputElement.hasAttribute('aria-invalid')) { </ins> this.inputElement.removeAttribute('aria-invalid'); this.hideMessage(); <del> } else { this.inputElement.setAttribute('aria-invalid', 'true'); this.showMessage(result); </del> } } <del> return !result; </del> <ins> return !errorMsg; </ins> } private stylesForType(type: MessageType): { border: Color; background: Color } {

Related discussion:
text: I would expect the info box to remain open and not close and open on each keystroke: ! /cc
duplicates
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 existing issues . See also our guidelines. Happy Coding!
Code change:
} public validate(): boolean { <del> let result: IMessage = null; </del> <ins> let errorMsg: IMessage = null; </ins> if (this.validation) { <del> result = this.validation(this.value); </del> <ins> errorMsg = this.validation(this.value); </ins> <del> if (!result) { </del> <ins> if (errorMsg) { this.inputElement.setAttribute('aria-invalid', 'true'); this.showMessage(errorMsg); } else if (this.inputElement.hasAttribute('aria-invalid')) { </ins> this.inputElement.removeAttribute('aria-invalid'); this.hideMessage(); <del> } else { this.inputElement.setAttribute('aria-invalid', 'true'); this.showMessage(result); </del> } } <del> return !result; </del> <ins> return !errorMsg; </ins> } private stylesForType(type: MessageType): { border: Color; background: Color } {

Related discussion:
text: Issue Type: <bBug</bTesting . 1) Start creating a new folder in the explorer 2) Type 'folder1/' -once the '/' is in the input box every keystroke afterwards causes a full flicker of the information widget shown below the input box. This also happens on other platforms. VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-27T06:17:53.785Z) OS version: Linux x64 4.4.0-59-generic Reproduces without extensions <!-- generated by issue reporter --
We need to debounce
Fixed by via
Code change:
if (Range.isIRange((obj as modes.Location).range) && URI.isUri((obj as modes.Location).uri)) { return extHostTypeConverter.location.to(obj); } <ins> if (obj instanceof VSBuffer) { return obj.buffer.buffer; } </ins> if (!Array.isArray(obj)) { return obj; }

Related discussion:
text: Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this
Code change:
const apiProposalNotListed = l10n.t("This proposal cannot be used because for this extension the product defines a fixed set of API proposals. You can test your extension but before publishing you MUST reach out to the VS Code team."); const implicitActivationEvent = l10n.t("This activation event cannot be explicitly listed by your extension."); const redundantImplicitActivationEvent = l10n.t("This activation event can be removed as VS Code generates these automatically from your package.json contribution declarations."); <ins> const starActivation = l10n.t("Using '*' activation is usually a bad idea as it impacts performance."); </ins> enum Context { ICON,

Related discussion:
text: We want to discourage extension authors from using activation. We should consider adding a diagnostic warning similar to the one we have for implicit events.
Is it not enough that provides the same prompt in terminal when packaging/publishing an extension?
at that stage in the development lifecycle, authors are more likely to just ignore the warning from vsce. Additionally, they might be publishing in CI and might not see it there either.
verification: in an extension, put in activation events see this: !
Code change:
} } const pickOptions: IPickOptions<PickStringItem> = { placeHolder: info.description, matchOnDetail: true, ignoreFocusLost: true }; <del> return this.quickInputService.pick(picks, pickOptions, undefined).then(resolvedInput => { </del> <ins> return this.userInputAccessQueue.queue(() => this.quickInputService.pick(picks, pickOptions, undefined)).then(resolvedInput => { </ins> if (resolvedInput) { <del> return resolvedInput.value; </del> <ins> return (resolvedInput as PickStringItem).value; </ins> } return undefined; });

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.63.2 OS Version: macOS 12.1 (ARM64) I can't get more than two launch configurations to run at the same time. I can run the rest of the configurations afterwards and everything works (debugging, etc.). StopAll will also only close the two configs that were successfully launched. I haven't found any mention in the documentation that this is limited to two launch configurations. I've only seen that two are used in every explanation or tutorial about this feature. Steps to Reproduce: multiple launch configurations in multi-root workspace inside of project roots. launch configurations to compounds in .code-workspace file debugging two of the many compound configurations will run Examples:
VS Code imposes no limit on number of launch configurations in compound config. I've verified this with this simple example project (which only relies on built-in VS Code features and not third-party extensions): unpack zip file in VS Code use "Open Workspace from file" to open workspace file inside folder switch to debug viewlet in debug config dropdown select and run "4 Debug Session" Observe: 4 debug sessions: <img width="1384" alt="CleanShot 2022-01-26 at 11 45 23 src="https://user-"Maybe there is a limit on dotnet/coreclr?
Thank you for taking a look at this After inspecting your configuration and some research in my own project I was able to isolate the culprit. The problem arises when you try to make use of inputs in the launch configuration.
Code change:
} } const pickOptions: IPickOptions<PickStringItem> = { placeHolder: info.description, matchOnDetail: true, ignoreFocusLost: true }; <del> return this.quickInputService.pick(picks, pickOptions, undefined).then(resolvedInput => { </del> <ins> return this.userInputAccessQueue.queue(() => this.quickInputService.pick(picks, pickOptions, undefined)).then(resolvedInput => { </ins> if (resolvedInput) { <del> return resolvedInput.value; </del> <ins> return (resolvedInput as PickStringItem).value; </ins> } return undefined; });

Related discussion:
text: I created a demo for download, the process is the same as you described above.
thanks for the additional info. I was able to create an even smaller repro without a multi-folder workspace: unpack zip file in VS Code open the "compound" folder switch to debug viewlet in debug config dropdown select and run "Compound" Observe: only one debug session starts
Is it possible to implement the input that allows blocking another input request until the first input has completed? Latter quick pick also cancels former ones so it needs to be fixed as well.
Do you own the configuration resolver Is my solution correct or should the service guarantee correct behavior when calling into it multiple times simultaneously?
your solution looks good. The configuration resolver service doesn't currently make any guarantees about what will happen if it's called into multiple time simultaneously. I would also be fine with the change being in the configuration resolver service though. We can change it's behavior so that it does make that guarantee.
Yes, making the fix in the configuration resolver service sounds better.
This fix doesn't fully cover our scenario (tested in latest insiders). This fixes case, and yet we also prompt for input or quick pick in , which is not covered in this PR. Is it appropriate to wait for as well?
Good point. Yeah, I think that makes sense.
I guess we'll need Queue's for and Would you like to make the changes, or should I work on this?
I can take care of it
This gets a bit weird. Since one launch config can be calling into the variable resolver (the first fix) while the second is calling the extension config provider, we also need a queue that orchestrates those two things. Easiest fix is to start launch configs one at a time instead of kicking them off in parallel: and I'm not sure what other impacts that could have. Perf to some extent, probably. So I wonder whether we would ever consider queueing calls into the quick pick control so that invoking the quick pick while it is already visible would wait instead of cancelling the first one as it does currently. Example of what I'm talking about (but in my real situation it's an extension competing with code in core): This extension code only shows one input box, while we could have the second wait for the first to complete. This could possibly be a breaking change for some extensions though, so it could be enabled with a flag.
Code change:
} } const pickOptions: IPickOptions<PickStringItem> = { placeHolder: info.description, matchOnDetail: true, ignoreFocusLost: true }; <del> return this.quickInputService.pick(picks, pickOptions, undefined).then(resolvedInput => { </del> <ins> return this.userInputAccessQueue.queue(() => this.quickInputService.pick(picks, pickOptions, undefined)).then(resolvedInput => { </ins> if (resolvedInput) { <del> return resolvedInput.value; </del> <ins> return (resolvedInput as PickStringItem).value; </ins> } return undefined; });

Related discussion:
text: As an easy workaround, I can put a queue around calling into the vscode variable resolver and calling an extension debug config provider. But, putting a queue around two unrelated pieces of code seems to say that I'm solving the problem at the wrong level.
Or maybe make them the same level by moving the resolve queue to
Just to be clear. The two callers of the are in two different places right (core and extension)?
Right
Ok I've not heard of any feature request like this but feel free to open one... I wonder if maybe instead Core could have concept of "important" quick picks that can't be stomped over by extensions and instead the extension calls wait until Core is done. Then we don't need any more API
It can also go the other way. The problem is just that there are two async processes that have to run and show a quick input, and we need both of them to complete and not to get canceled by the other. Filed I'll go with a workaround for now, so I'm not blocked, just figured I'd start the discussion
Sorry for the late reply. I tested this today and it works for our scenario. Thanks for the quick fixes!
Code change:
this.continueEditSessionOptions = continueEditSessionOptions; }); <ins> this.shouldShowViewsContext = EDIT_SESSIONS_SHOW_VIEW.bindTo(this.contextKeyService); </ins> textModelResolverService.registerTextModelContentProvider(EDIT_SESSIONS_SCHEME, instantiationService.createInstance(EditSessionsContentProvider)); }

Related discussion:
text: fyi
Verification: opt into edit sessions using , then ensure the edit sessions view does not appear in the sidebar until you run the Show Edit Sessions action in the command palette.