"Couldn't start client JSON Language Server" error

[DanTup]

I'm getting this error when opening launch.json on my Mac (pretty sure it doesn't happen on my PC). Restarting Code code has had no effect.

As far as I can tell, the Code Helper it's looking for does exist at that location:

Anything I can do to debug (it's possible uninstalling/reinstalling Code will fix; but there may be value in understanding what's happened?)

[DanTup]

The other path mentioned also seems to exist:

[DanTup]

Trying to run it manually gives this error, seems like there's no Resources folder inside Code Helper?

[aeschli]

@DanTup In what build do you see this?

[DanTup]

Stable 1.20.0, it auto updated to it a few nights ago

[aeschli]

I tried with 1.20 c63189d, and all seems to work for me.
I can open debug.json.

@DanTup Can you reinstall VSCode ?

[DanTup]

I deleted it from Applications then downloaded using the Stable link on the website; extracted the zip, dragged the .app into Applications and launched. Same thing :(

[aeschli]

Also make sure that all instances of VSCode are closed.
cc @joaomoreno

[DanTup]

It was completely closed before I deleted it. I even launched the .app I extract directly from another location and had the same issue (though the paths were different, pointing at a temp location where Mac OS seemed to have put the app to run it).

I just downloaded the Mac package again (from here) on my PC and opened it up and I can see there's no resources folder inside the path from the error message up top.

Does this not happen for any of you if you install/run the official package being served up (I don't think running from the repo commit is a good test)?

[joaomoreno]

@DanTup Close all files in Code. Shutdown Code. Open Code. Open devtools. Any errors there?

Now, open launch.json. Do the errors come up then?

[DanTup]

Strangely, I cannot repro this today. I'd definitely closed all Code windows and rebooted (many times) between the update and experiencing this (restarting again was one of the first things I did before raising). I also completely removed and reinstalled it and still had the issue.

I don't know what project I had open at the time, but I tried a few now and can't repro (I tried with launch.json open already and also opening it after loading, and I tried in both the main instance and the dev host).

I'll do some more testing later, but I'm kinda baffled by this; it absolutely wasn't just a case of not restarting Code since the update, that I'm positive of.

[joaomoreno]

Alright, let us know if it comes back.

[DanTup]

Hit it again - but on my PC this time! So it's not isolated to Mac :(

[Error - 13:38:06] Starting client failed
Error: spawn C:\Program Files (x86)\Microsoft VS Code\Code.exe ENOENT
	at exports._errnoException (util.js:1050:11)
	at Process.__dirname.ChildProcess._handle.onexit (internal/child_process.js:193:32)
	at onErrorNT (internal/child_process.js:367:16)
	at _combinedTickCallback (internal/process/next_tick.js:80:11)
	at process._tickCallback (internal/process/next_tick.js:104:9)

I tried closing and re-opening the projects, but it didn't occur the second time... I'll try and do some more debugging after lunch.

[joaomoreno]

OK, let me know if you can repro it better. cc @bpasero @alexandrudima for more eyes on this

[DanTup]

Ok, I can repro this by putting the bad path into the top of any .code-workspace file:

{
	"folders": [
		{
			"path": "../testse-tests"
		},
		{
			"path": "M:\\Coding\\Applications\\flutter\\packages\\flutter_tools"
		},
		{
			"path": "M:\\Coding\\Applications\\flutter\\dev\\devicelab"
		}
	],
	"settings": {
	}
}

[joaomoreno]

I've very confused now. Exactly what happens when you put the bad path into the top of any .code-workspace file? The Couldn't start client JSON Language Server error simply comes up?

[DanTup]

Apologies, I've been confused too!

Basically the bug is that if there is a bad nonexistant path in the code-workspace file (like the "path": "../testse-tests" in my previous comment) then when you open that workspace in Code, you'll get the JSON service error.

[DanTup]

I've removed the comments from when I was digging into this that turned out to be unrelated, hopefully it reads better now.

[joaomoreno]

Awesome, thanks. Seems like a great find!

Also, by bad path... that means a path which does not exist in disk?

[DanTup]

Yep, sorry. The repo I was using had a relative path to another repo that was normally checked out alongside it, so it was referencing a missing folder for me.

[aeschli]

The problem is that when the language client spawns the language server it uses the first workspace folder as the cwd of the process.

[aeschli]

There are multiple other exceptions in the console:

• git (@joaomoreno)

[Extension Host] rejected promise not handled within 1 second (at Console.originalConsole.(anonymous function) [as warn] (/home/aeschli/workspaces/vscode/extensions/git/node_modules/diagnostic-channel-publishers/dist/src/console.pub.js:42:39))

• ripgrep (@roblourens)

[Extension Host] [IPC Library: Search] spawn /usr/share/code-insiders/resources/app/node_modules/vscode-ripgrep/bin/rg ENOENT (at /usr/share/code-insiders/resources/app/out/vs/workbench/services/search/node/searchApp.js:147:153) (at Console.originalConsole.(anonymous function) [as error] (/usr/share/code-insiders/resources/app/extensions/git/node_modules/diagnostic-channel-publishers/dist/src/console.pub.js:42:39))

I'll add a test to the language server, but I wonder if we should filter such folders from the API? @bpasero

[DanTup]

The problem is that when the language client spawns the language server it uses the first workspace folder as the cwd of the process.

What happens if you just don't set a cwd? It can't be used for anything important if you're just arbitrarily picking one? 😀

[bpasero]

@aeschli I would not do that, an extension has to always assume that a workspace folder of a multi root configuration is invalid (for example, a user might have a workspace where some folders point to an external hard disk which is not always connected).

It is true that this never happened before where you could only open a single folder which always had to exist. However, I would not want to add some throw-away code to handle the "first folder" case specifically because that one is deprecated API anyways.

It is good to force extensions to think about the case where the first (or any) folder is not there, extensions need to deal with this imho.

[aeschli]

microsoft/vscode-languageserver-node#310 is the issue on the LSP side.

[aeschli]

Created #43580 and #43579 for the git and ripgrep errors

[alexdima]

Related: #43493

[joaomoreno]

@bpasero I'm not so convinced that is the case. We're forcing all extensions to simultaneously check for fs.exists. Why shouldn't this be handled by the platform? As an extension author, I assume that if the API tells me the workspace has folders A, B, C, I think it's very reasonable to assume that those folders exist. Every extension will do so.

[bpasero]

@joaomoreno but it is not that easy, an extension might want to use the new API to change workspace folders programmatically and now suddenly those that do not exist on disk are not showing up anymore? I think we are telling the wrong story to extensions if we decide to not include those that currently are not existing on disk.

[roblourens]

What's the use case for an extension adding workspace folders that don't exist?

Unless there's a really good scenario, I don't think we should leave it up to every extension to check that every workspace exists.

[bpasero]

@roblourens I was not referring to adding a folder that does not exist but managing the set of workspace folders in any way (e.g. that could also include showing a workspace folder picker to do some more stuff with it like allowing to rename a folder).

I think it boils down to the question what WorkspaceFolder is defined as: the list of folders as defined in the workspace configuration file (my preference), or the list of folders that actually exist on disk.

[aeschli]

Closing as the JSON language server has been fixed.