Code change:
VS Code Version: 1.85.2 OS Version: Linux (OpenSUSE Tumbleweed) as well as Windows 10 If I create an automatic folderOpen task in a folder that I access through VS Code's Remote SSH extension, this task is sometimes run when I open my folder, but it often isn't. It's simple for me to reproduce this on both Windows and Linux, and also with the latest (as of today) Insiders build on Windows. It seems timing related. It also seems like it's less likely to happen if I keep a file open in the workspace when I close it, so that the same file is automatically opened when I open it the next time. I've trusted the workspace. I have put together a minimal containerized SSH server with a tiny workspace to reproduce this, see I start the container and then connect to it with VS Code over SSH. Please note that the main issue isn't with this container setup. I'm seeing this when connecting to normal remote SSH servers as well. The container is just an attempt to build a minimal reproducible setup, as well as to avoid publishing private details in this report. I have also some extra logs to VS Code's source code to try to debug this, see this commit: I unfortunately wasn't able to get the remote ssh extension working properly with my custom VS Code OSS build. From what I can tell, it seems that Microsoft actually doesn't want me to do that. But I was able to find the corresponding places in the minified file for my proper VS Code installation, and put my extra logs there instead. With those changes, the logs from a typical bad run (on Windows) look like this: The logs from a typical good run (on Windows) look like this: The main difference between these two runs is in what's assigned to in (), when () tries to fetch the folderOpen tasks (). In the good case, I get a config object containing my task. In the bad case, there is no such config object. This is also reflected in the log I to (), where the array is empty in the bad case. Please note that in the bad case, there is an update of the tasks fetched in the task service happening soon after VS Code tried to run the automatic tasks. You can see that is called with runSource=3 (i.e. ), and that the subsequent variable assignment actually contains my task. Unfortunately, the code to run the automatic tasks has already been triggered by this time, and isn't retriggered. In the good case, there is no such update of the fetched tasks based on reconfiguration. But the fetched tasks are also updated when the automatic task is run, which is why you can see similar traces but with . Steps to Reproduce: a container like the one in gist your .ssh/config file to access the containerized SSH server (optional) Patch your VS Code build (the minified if you can't use remote SSH with a custom build) to get more logs, like to the remote SSH workspace and trust it a couple of times and note that the automatic task isn't always started
thanks for all of the info. Not sure when I'll get to this, feel free to submit a PR if you can find the fix.
Many thanks for acknowledging this! I might try to make a fix, but it's a bit complicated to test it as it seems I'm not allowed to use the Remote SSH extension together with my custom VS Code OSS build. Then I need to continue hacking the minified workbench js file of my normal VS Code installation instead, like I did to add the extra logs. Is there any way around that, that you are allowed to share?
would know more about selfhosting the remote setup.
I learned that it will indeed be hard to self host this/test it. I'll probably need to make a custom build to do so. Thanks for the investigation
I tried something out here: It seems to work fine when I add the corresponding code to the minified file as well. Waiting for task reconfiguration for some extra time if the automatic task count is zero isn't the prettiest solution, of course, but please have a look if you have the time.
Thank you, your changes look good. I pulled most of them over and am creating a custom test build for verification.
Nice! You can probably skip the final two if statements in tryRunTasks, then, as you kept them in runWithPermission instead.
was able to test and verify your changes fix the issue! I have a branch ATM with the changes ready to go. Do you want to copy them over and create the PR so you get credit?
Great news! Sure, I could do that. Credit is not super important to me, but it's always good to know whom to blame... :⁠-⁠) I can give it a go later today. It was a while since I did that on GitHub, but I'll probably manage.
Also no pressure , just wanted to offer. I can instead create the PR myself and give you credit in our release note thank yous section. Just LMK which you'd prefer.
I'll give it a go. It's a good exercise. Do you have any guidelines for commit messages and such?
I think I managed to do it correctly! :smile:

Related discussion:
text: } this._setTaskLRUCacheLimit(); <del> return this._updateWorkspaceTasks(TaskRunSource.ConfigurationChange); </del> <ins> await this._updateWorkspaceTasks(TaskRunSource.ConfigurationChange); this._onDidChangeTaskConfig.fire(); </ins> })); this._taskRunningState = TASK_RUNNING_STATE.bindTo(_contextKeyService); this._onDidStateChange = this._register(new Emitter());