Dockerfile Language Server cannot start right after installing the extension

[rcjsuen]

1. Install the Container Tools extension.
2. Install the Docker DX extension.
3. Disable the Container Tools extension.
4. Command Palette > Developer: Reload Window
5. Open a Dockerfile.
6. Enable the Container Tools extension. You will see error toasts popup.

Essentially, this issue only happens if you install Docker DX first and then install Container Tools. If you restart this problem won't happen. From what I can tell it only triggers if you install/enable the Container Tools extension while the Docker DX extension has already been activated.

[bwateratmsft]

I can reproduce. I think it's because Docker DX is now starting the same Dockerfile language server. We get a conflict on language client initialization:

[error] command 'docker.command.convertToLowercase' already exists {"errorType":"Error","message":"command 'docker.command.convertToLowercase' already exists","stack":"Bb.registerCommand extensionHostProcess.js:112:40259\nObject.registerCommand extensionHostProcess.js:168:101569\nExecuteCommandFeature.register extension.bundle.js:2:4378841\nExecuteCommandFeature.initialize extension.bundle.js:2:4378407\nLanguageClient.initializeFeatures extension.bundle.js:2:1660509\nLanguageClient.doInitialize extension.bundle.js:2:1647053\nLanguageClient.start extension.bundle.js:2:1644066\nextension.bundle.js:2:5815406extension.bundle.js:2:5815406","isUserCancelledError":false}

Remy Suen (@rcjsuen) we need to work out a strategy to make sure only one of these language servers is running at a time.

I see there is guard code around the server launch in Docker DX: https://github.com/docker/vscode-extension/blob/43dac4fd477388fba56de6196fc384c0d96e8f57/src/utils/lsp/lsp.ts#L303-L311

However, this won't apply if Container Tools is installed or enabled after Docker DX has activated.

[rcjsuen]

Ah, that certainly explains the error. Thank you for finding that stack trace.

[bwateratmsft]

I don't think it's super high priority to get a fix in for this, since reloading the window "cures" it, and doing odd combinations of uninstalling/reinstalling/disabling/enabling extensions won't be too common. I wonder if there's an API in VSCode to discover other extensions' language clients to see if this one is already started...

[bwateratmsft]

I did a little research today and found some options for dealing with the issue.

1. Sharing a semaphore with Docker DX by way of extension API. The most complex solution but probably the most robust and fastest at runtime.
2. Sharing a semaphore with Docker DX by way of VSCode contexts, i.e. vscode.commands.executeCommand('setContext', 'foo', 'bar'). However, performance is not great (~35ms), and I couldn't actually find a good way to retrieve already-set contexts. There is no getContext command. There is a getContextKeyInfo, but when I tried it did not contain the value I had just set.
3. Using vscode.commands.getCommands(true) to look to see if one of the commands in question is already registered. This is robust and easy to implement, but even slower, at ~20-150ms.

I did look into LanguageClientOptions.initializationFailedHandler, and while this can be used to stop attempts at restarting the server, it did not seem possible to cause it to just eat the error message--the language client still reported it. The error notification is forced, overriding revealOutputChannelOn. errorHandler seems to be for runtime errors, not init errors.

No luck finding VSCode APIs to discover other language services.

[bwateratmsft]

We talked internally and think the best solution for now is to catch the error and emit a better one, with a button to reload the window (or just restart extensions?), which cures the problem.

Having anything that affects activation perf every time for a scenario that would occur so rarely seems wrong.

[bwateratmsft]

Well, regrettably, so many toasts pop up that the one I added gets buried. What you see:

And if you expand notifications by clicking the bell:

And there are still two more behind a scrollbar. Yuck.

So I guess we will won't-fix this, since there's nothing we can do to control all those toasts.