Code change:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

Related discussion:
text: const processContext = ProcessExecutionSupportedContext.bindTo(this._contextKeyService); processContext.set(process && !isVirtual); } <ins> // update tasks so an incomplete list isn't returned when getWorkspaceTasks is called this._workspaceTasksPromise = undefined; </ins> this._onDidRegisterSupportedExecutions.fire(); }