Task doesn't run on folder open anymore

[jrieken]

• https://github.com/microsoft/vscode-github-issue-notebooks
• notice that the task.json has a "runOn": "folderOpen"-script
• run the task manually
• reload window
• 🐛 the task doesn't start automatically

[jrieken]

cc @alexr00 you fixed this in the past

[meganrogge]

I certainly caused this w the task reconnection - will look into it

[meganrogge]

this is working for me now - likely fixed with one of my recent PRs related to automatic tasks

[jrieken]

Sorry, this doesn't work

[meganrogge]

@jrieken you need to allow automatic tasks to run. have you run

[meganrogge]

autotasks.mov

[jrieken]

Screen.Recording.2022-09-27.at.15.29.13.mov

[jrieken]

@jrieken you need to allow automatic tasks to run. have you run

Why is this now needed? I have trusted this workspace and I have run this exact task successfully in the past?

[meganrogge]

it's always been needed. if you've ever hit disallow, it won't work. once you've allowed for the folder once, you shouldn't have to again

[jrieken]

it's always been needed.

I doubt that's true. When I hit allow it writes a workspace setting and that wasn't needed, it came in via #154171. I have been using this feature years before this change - albeit infrequently in side projects.

I already have the "runOn": "folderOpen"- option and I have given trust to the folder. So, why do we put up further hurdles to use this feature?

[meganrogge]

#154171 was added to prevent these tasks from running automatically without consent of the user in a workspace that may or may not have been set up /configured by them.

[meganrogge]

some people can find it jarring and unwanted if they run automatically - even if they trust the workspace and happen to have that in their tasks.json file

[Tyriar]

If I'm remembering right there was always an opt-in via notification (maybe requiring engaging with the task system before it shows?). Whether a task runs on startup is a user preference, so instead of a hidden preference stored in local storage, tasks has moved to a setting. Is the problem that there was no migration to the setting?

[meganrogge]

Is the problem that there was no migration to the setting?

Yes I think so

[jrieken]

If I'm remembering right there was always an opt-in via notification

Looping in @alexr00 for reference but if I remember correctly this notification was the workaround for the lack of workspace trust. We prompted folks with an FYI to ask them for consent - similar prompts existed for eslint or tsserver and workspace trust is the answer

Whether a task runs on startup is a user preference,

No. This is a workspace configuration file which means "team preference". It is the same as using source maps for debugging or not. Or what typescript version to use etc. Also, the "Manage Automatic Tasks in Folder" writes a workspace setting not a user setting

[Tyriar]

Looping in @alexr00 for reference but if I remember correctly this notification was the workaround for the lack of workspace trust. We prompted folks with an FYI to ask them for consent

It was added here #64613, derived from this terminal change #23362. The discussion in the terminal feature request is here: #19758.

I did remember some of this wrong after digging into it and it was added primarily for security, but it's not the only reason for it now. The UX of this is an important part that was refined over time and carried over to terminal profiles; I have a preference of never wanting a workspace to modify my default terminal profile, regardless of whether I trust it.

No. This is a workspace configuration file which means "team preference".

@jrieken I disagree, I've always had auto run tasks disabled as I want to control when they run. This was a consideration when the notification was added. Source maps are a bad comparison as if they work they're almost always a better experience (though I often disable them to access ran variable names).

Also, the "Manage Automatic Tasks in Folder" writes a workspace setting not a user setting

Yes, we simplified it from opt-in to auto running tasks per workspace as that's handled by workspace trust now, to simply "am I a user who wants to enable auto run tasks?". That seems like it aligns with you wanting to have them always enabled and me wanted to have them always disabled.

[jrieken]

I have a preference of never wanting a workspace to modify my default terminal profile, regardless of whether I trust it.

I also have many my preferences but the team preferences overrule them: source maps, prettier, lint rules etc pp. That's part of agreeing what are team and personal settings. As a side note: I am not aware that auto tasks have ever been a topic for us (VS Code) and I also don't see any of them in our task.json file. Don't get me wrong: I am happy with a "overrule team decision and go with my preference" path. I think this applies to a few none-critical things, like I want that for source maps.

Anyways, the implementation for auto-run task is poor:

• no migration, essentially breaking the feature
• the "manage automatic task in folder"-command writes a team/workspace-setting which defeats the purpose of overruling team configuration
• the default value for task.allowAutomaticTasks is auto. Its docs say "Prompt for permission for each folder" which is not true and misleading

[meganrogge]

My initial feeling about this was if the folder is trusted, the tasks should run automatically when configured to do so.

Several points I encountered when I raised this were:

the manage automatic tasks command has been around for a long time and we didn't want to remove it for those that are used to it

The setting would make it easier and more discoverable to manage automatic tasks.

I am in favor of removing the prompt per folder and respecting 1) a trusted workspace 2) the setting as configured via the actions or directly.

I am also in favor of making this a user setting instead of a workspace/folder specific one.

[jrieken]

of removing the prompt per folder and respecting 1) a trusted workspace 2) the setting as configured via the actions or directly.

I like that but the action shouldn't write a workspace-setting because task.json is already a "workspace setting". I would argue this should only be allowed as user-setting (which I believe our settings model supports). Also, the default should be on because you conflict team-choice - doing that shouldn't be default. In untrusted workspaces don't ever auto-run a task and maybe show a squiggle in task.json that signals that

[meganrogge]

Yes I meant as a user setting and agree with you re untrusted workspaces

I am in favor of making this a user setting instead of a workspace/folder specific one.

[meganrogge]

We're bringing this to the UX sync to decide what the right approach is

[meganrogge]

Proposal:

Untrusted: ❌ automatic tasks
Trusted: ✅ based on user setting

[meganrogge]

Approved in the UX sync

[meganrogge]

Storage target will now be user and storage scope will be profile