Change:
Does this issue occur when all extensions are disabled?: Yes VS Code Version: Version: 1.77.1 (user setup) Commit: Date: 2023-04-04T23:21:11.906Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No OS Version: Windows 10 Enterprise Build .2728 Steps to Reproduce: Create a .code-workspace file and open the workspace (mine is a multi-root workspace). Create a custom task under "tasks" property (example below) ! Open the command palette and type "Tasks: Run Task" Ideally you should see your workspace level created tasks under the command palette, but it only shows other options (image below): ! One thing that I noticed is that if you create an empty file in any of the projects inside the workspace it will show the tasks. It also will show tasks if you delete an empty file. But after closing vs code it will still not be showing the tasks under command palette. !
Same issue for me after automatic update to 1.77.3: Version: 1.77.3 (user setup) Commit: Date: 2023-04-12T09:16:02.548Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No This is really a big problem in our development environment, therefore I reverted my installation to an earlier version to avoid this problem and deactivated updates for now.
this is working for me in insider's https://user-
I did some checks. It was working up to version 1.74.3 and seems to be broken with 1.75.1 and higher versions. First broken version: Version: 1.75.1 Commit: Date: 2023-02-08T21:32:34.589Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No
I cannot reproduce. Have you tried insider's?
I have a similar problem, which might be related. I suspect the "defined in the .code-workspace file" to be a red herring, that's why I'm adding it here instead of starting a new issue. In my case the build tasks are defined in the file of a single-folder workspace. This is a C program and the workspace has the "C/C++" extension enabled. When I select "Run build task..." only the extension-defined "build active file" targets are shown. But this only happens on the first start after boot, so I suspect it's a timing issue that's mended by fs caching. I known, because at least in my case there's an easy workaround, which is why I haven't reported it yet. But it might give a hint what's happening: When I run one of the default compile targets (which will fail), the build tasks from are shown in subsequent invocations of "Run build task...". I can't reproduce the issue in insiders, but I guess that's because it loads less extensions and it's probably a timing issue. (But after I started insiders it also works in release first try). I can also confirm that it already started some versions ago, but I didn't do any more research. 1.75 might be about right, though. It would probably be hard to come up with a reproducible example, but I'm happy to provide relevant logs, if there are any. This is from the insiders version I used: Version: 1.78.0-insider Commit: Date: 2023-04-18T05:23:26.269Z Electron: 22.4.5 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Linux x64 6.2.12-arch1-1 Sandboxed: Yes ``'
No, I haven't. Thanks for that hint! I can confirm that this "workaround" is also working for me. You can run a default build task and let it fail or even kill it before completing. The next time I call the build tasks all my tasks from are shown.
"workaround" also works here
Maybe this helps: Every time it doesn't work, there seem to be a bunch of these messages in the "Tasks" output (like this, including the extra LFs): The number of messages seems to match the number of tasks defined in .
I get the . I suspect that since I'm running on a machine from 2015, and I've had to increase the to beyond the default of 10 seconds, that the tasks get skipped during initialization because the terminal shell module has not finished initializing. The workaround is to run the command and then the tasks are available.
thanks for the info, there were a few commits that could've caused this that were made in March. investigating
reverting this commit fixes it for me
What i think would fix this is awaiting when the run task command is invoked.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
this was easy to repro - just have no file in a workspace where you have defined tasks. then run the command and verify your workspace task is listed
FYI, this issue still exists for me in 1.80.0 (I understand that if it was in insiders two weeks ago it should be in the release?). I tried to reproduce it with insiders at the time and couldn't, but it never was 100% reproducible for me and who knows which relevant factors are different when running insiders (FWIW, I did copy my to before the test).
can you provide the exact steps you're reproducing it with? this works for me in insider's
There aren't really steps, it's like I wrote and : I just open a (in my case single-folder) workspace which has a few (C-) build tasks defined in . Then when I try to run a build task (Ctrl-Shift-B), usually (but not always) only the extension-defined build tasks ("build active file") are shown. This also usually only happens after the first start of vscode after a fresh boot and when it happens the "Warning: process tasks are unavailable in the current environment." messages are shown in the "Tasks" output. And after I ran one of the visible default build tasks the missing tasks are shown, too, for the rest of the session. For me, this all points to a subtle timing issue. I could try to come up with a simple test case, but I doubt that it's worth the effort as you then probably still couldn't reproduce it. (As I said, I can't even reproduce it with insiders, for some reason). So I think it would be more promising if there maybe are relevant logs other than the warnings I cited.
Thanks! Could you give me a hint how I could best replicate the standard vscode environment in insiders, in order to test this? Copying to wasn't enough, e.g. extensions which I globally disabled in standard were still enabled.
I'm not sure what you mean - can't you just open your project in Insider's?
Yes, but I've never been able to reproduce the bug with insiders (even with old versions that definitely still had the bug). I suspect this is because insiders seems to have it's own, separate configuration (like installed/enabled extensions), Which makes sense, but is probably the reason why I can't reproduce the bug, as I suspect it's timing related. Manually cloning the configuration is cumbersome, that's why I hoped to just copy it from the release version. But just copying to doesn't seem to sufficient.
In the next release IE 1.81.0, I believe this will have been fixed. So maybe hang on until then to test it?
Sure, no problem. I just thought I maybe could speed up the feedback cycle :)
Thanks
I can confirm that it consistently works for me in 1.81 :tada: Thanks!

Discussion:
}); } <del> public async getTask(folder: IWorkspace | IWorkspaceFolder | string, identifier: string | ITaskIdentifier, compareId: boolean = false, type: string | undefined = undefined): Promise<Task | undefined> { </del> <ins> public async getTask(folder: IWorkspace | IWorkspaceFolder | string, identifier: string | ITaskIdentifier, compareId: boolean = false): Promise<Task | undefined> { </ins> if (!(await this._trust())) { return; }

} // We didn't find the task, so we need to ask all resolvers about it <del> const map = await this._getGroupedTasks({ type }); </del> <ins> const map = await this._getGroupedTasks(); </ins> let values = map.get(folder); values = values.concat(map.get(USER_TASKS_GROUP_KEY));

await this._updateWorkspaceTasks(); const taskFolder = task.getWorkspaceFolder(); const taskIdentifier = task.configurationProperties.identifier; <del> const taskType = CustomTask.is(task) ? task.customizes()?.type : (ContributedTask.is(task) ? task.type : undefined); </del> // Since we save before running tasks, the task may have changed as part of the save. // However, if the TaskRunSource is not User, then we shouldn't try to fetch the task again // since this can cause a new'd task to get overwritten with a provided task. taskToRun = ((taskFolder && taskIdentifier && (runSource === TaskRunSource.User)) <del> ? await this.getTask(taskFolder, taskIdentifier, false, taskType) : task) ?? task; </del> <ins> ? await this.getTask(taskFolder, taskIdentifier) : task) ?? task; </ins> } await ProblemMatcherRegistry.onReady(); const executeResult = runSource === TaskRunSource.Reconnect ? this._getTaskSystem().reconnect(taskToRun, resolver) : this._getTaskSystem().run(taskToRun, resolver);

const taskDefinitionsExtPoint = ExtensionsRegistry.registerExtensionPoint<Configuration.ITaskDefinition[]>({ extensionPoint: 'taskDefinitions', <del> activationEventsGenerator: (contributions: Configuration.ITaskDefinition[], result: { push(item: string): void }) => { for (const task of contributions) { if (task.type) { result.push(`onTaskType:${task.type}`); } } }, </del> jsonSchema: { description: nls.localize('TaskDefinitionExtPoint', 'Contributes task kinds'), type: 'array',