Same issue for me after automatic update to 1.77.3:

Version: 1.77.3 (user setup)
Commit: 704ed70
Date: 2023-04-12T09:16:02.548Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Windows_NT x64 10.0.22621
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-images.githubusercontent.com/29464607/232115319-15a11b06-a464-4ba2-a9bc-43fab7f8b14b.mov

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: 441438a
Date: 2023-02-08T21:32:34.589Z
Electron: 19.1.9
Chromium: 102.0.5005.194
Node.js: 16.14.2
V8: 10.2.154.23-electron.0
OS: Windows_NT x64 10.0.22621
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 tasks.json 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 tasks.json 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.

Version: 1.77.3
Commit: 704ed70d4fd1c6bd6342c436f1ede30d1cff4710
Date: 2023-04-12T09:16:52.732Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Linux x64 6.2.12-arch1-1
Sandboxed: No

This is from the insiders version I used:

Version: 1.78.0-insider
Commit: 95396f14dbae4d5def754d8635010f8e5743f56c
Date: 2023-04-18T05:23:26.269Z
Electron: 22.4.5
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Linux x64 6.2.12-arch1-1
Sandboxed: Yes
``'

I cannot reproduce. Have you tried insider's?

No, I haven't.

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 tasks.json are shown in subsequent invocations of "Run build task...".

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 tasks.json are shown.

I cannot reproduce. Have you tried insider's?

No, I haven't.

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 tasks.json are shown in subsequent invocations of "Run build task...".

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 tasks.json 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):

Warning: process tasks are unavailable in the current environment.

Warning: process tasks are unavailable in the current environment.

Warning: process tasks are unavailable in the current environment.

Warning: process tasks are unavailable in the current environment.

The number of messages seems to match the number of tasks defined in tasks.json.

I get the Warning: shell tasks are unavailable in the current environment. I suspect that since I'm running on a machine from 2015, and I've had to increase the application.shellEnvironmentResolutionTimeout 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 Developer: Reload Window 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 31ed7f7

What i think would fix this is awaiting getWorkspaceTasks when the run task command is invoked.

This bug has been fixed in the latest release of VS Code Insiders!

@raphabg, you can help us out by commenting /verified if things are now working as expected.

If things still don't seem right, please ensure you're on version 4649b53 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!

@TylerLeonhardt this was easy to repro - just have no tasks.json file in a workspace where you have defined tasks. then run the run task 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?).

Version: 1.80.0
Commit: 660393deaaa6d1996740ff4880f1bad43768c814
Date: 2023-07-04T13:39:48.236Z
Electron: 22.3.14
ElectronBuildId: 21893604
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Linux x64 6.4.2-arch1-1

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 .vscode to .vscode-insiders 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 here and here: I just open a (in my case single-folder) workspace which has a few (C-) build tasks defined in tasks.json.

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 ~/.vscode to ~/.vscode-insiders 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?

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 ~/.vscode to ~/.vscode-insiders 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?

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 🎉 Thanks!