affectsConfiguration() returns true when a project is removed in a multi-workspace instance

[OrkunTokdemir]

affectsConfiguration("my_config", my_workspace_folder) returns true when I remove my_workspace_folder from the multi-workspace instance. This leads to bugs on our end. I would expect it to be not triggered for those situations. Is there any workaround for this problem?

I have a similar configuration in my workspace setting.json

"my_config.myval": true

[isidorn]

Well that sounds like the right behaviour to me. Why is this unexpected?

[OrkunTokdemir]

The workaround shared in microsoft/vscode#66246 (comment) doesn't fix my problem. To be more specific, when a configuration is changed, our extension restarts our language server with the new parameters. When affectsConfiguration() is triggered before onDidChangeWorkspaceFolders() by removing, we start a dangling language server. Our workaround would be either stopping the dangling language server or aborting starting it when onDidChangeWorkspaceFolders() is triggered but it is a dirty workaround which I avoided from the beginning.

[sandy081]

To be more specific, when a configuration is changed, our extension restarts our language server with the new parameters.

Can you please explain this more? Do you restart on any configuration change or for a specific change?

[OrkunTokdemir]

We restart it using a specific language server configuration change. For example, users can provide some import paths for the language server. When an import path is either added or removed, the language server is restarted with the new import paths.

[sandy081]

So why not checking if that particular configuration has changed or not whenever there is a config change event. Restart only when that specific config has changed.

[OrkunTokdemir]

We already check for a particular configuration change.

Let me explain in more detail.

affectsConfiguration(<some_config>, my_workspace_folder) -> Checks the specific configuration and restarts the language server with new parameters
onDidChangeWorkspaceFolders() -> If a workspace is removed, the extension stops the language server.

When a workspace is removed, affectsConfiguration() returns true, and the extension restarts the language server. Then, onDidChangeWorkspaceFolders() is triggered, and the workspace is removed, but it cannot stop the language server because it is being initialized. In the end, we don't have the workspace but a language server working for the removed workspace, which becomes a kind of dangling language server.

I think there is a bug in affectsConfiguration() for the case when the workspace parameter is passed and the workspace is removed. It should return false but returns true, which misleads the execution on the extension side. There is no way to understand whether the configuration is removed by the user or by the workspace removal.