Registering workspace/didChangeWorkspaceFolders failed due to an invalid parameter (registrations)

[reykjalin]

Describe the bug

When starting the language server in Nova Intelephense reports that Registering request handler for workspace/didChangeWorkspaceFolders failed due to an invalid parameter (registrations), despite that parameter being defined in the spec.

I'm making the assumption that this error is being thrown in the client/registerCapability handler.

The language server runs perfectly fine after this, but due to the exception thrown a pop-up shows up every time the server is started. Not super annoying but less than ideal.

The full error log

Initialising intelephense 1.5.4
Initialised in 13 ms
Registering request handler for workspace/didChangeWorkspaceFolders failed.
(node:2598) UnhandledPromiseRejectionWarning: Error: Invalid parameter: registrations
Registrations must be of type Registration[]
    at /usr/local/lib/node_modules/intelephense/lib/intelephense.js:3:168725
    at /usr/local/lib/node_modules/intelephense/lib/intelephense.js:3:169019
    at Immediate.K.C.size.setImmediate (/usr/local/lib/node_modules/intelephense/lib/intelephense.js:3:169378)
    at runCallback (timers.js:705:18)
    at tryOnImmediate (timers.js:676:5)
    at processImmediate (timers.js:658:5)
(node:2598) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:2598) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Indexing started.
Indexing ended. 95 files indexed in 0s.
Writing state to /var/folders/v5/7bpkhftj1x7578skzgnlf50c0000gn/T/intelephense/33acabec.
Wrote state in 0.1s.

To Reproduce

You can install the trial edition of Nova and install the Intelephense extension I just published.

Expected behavior

No exception thrown.

Platform and version

• macOS v10.15.7
• Intelephense v1.5.4, installed via npm.
• Nova v3.1 -- Build 221256

[reykjalin]

I should also mention @bmewburn; if you have any issues with the extension itself being published, I can remove it. Likewise, if you want the extension to use a different name/icon/etc. I will respect those wishes.

I'll publish the source once the integration is more stable, and not throwing an error 🙂

All the extension does is act as an LSP client to Intelephense.

[chipotle]

Hi, @reykjalin - I was actually just about to write you email, but discovered this when I was searching this console error message. :)

I was also exploring an Intelephense extension for Nova and found this same blocking point, after several other blockers that changed depending on the version of Nova - this makes me suspect the issues are on Nova's end, despite the editor working with (some?) other language servers. My off-the-cuff guess is that Nova is sending things that are technically out of LSP's spec, but some other servers are letting it slide. In any case, it's very likely up to @panicinc to address this; you might want to send the bug to them. I've sent an earlier version of it to them, got a bit of feedback on it, then nothing more. ¯\_(ツ)_/¯

Personally, I think it's probably best not to have an "Intelephense extension" available in Nova's extension directory that's nonfunctional; users are just going to download it and be disgruntled. The hope I had was to be able to publish one with a bundled Intelephense (if @bmewburn was okay with that once it started working, of course), and to have the ability to enter the "premium version" license code in the preferences (assuming Nova's API is, or becomes, good enough to both use the premium features and pass the license code to Intelephense!). You could do that, of course, at least once it's all working!

[reykjalin]

My off-the-cuff guess is that Nova is sending things that are technically out of LSP's spec

That might very well be, but that doesn't seem to be what's causing the error. The error I'm seeing is thrown for something that is defined by the spec. That's not to say that there isn't anything wrong in Nova's implementation of the protocol, but at the least that doesn't seem to be the issue here.

In addition to that, the exception is thrown in the Intelephense code, not Nova's JS engine. I can't even catch or manage the exception in any way from Nova, so I do think @bmewburn's input is required here, and possibly some changes to how Intelephense handles the registration of the workspace/onDidChangeWorkspaceFolders method.

Personally, I think it's probably best not to have an "Intelephense extension" available in Nova's extension directory that's nonfunctional

I would agree with this, but the extension is functional; I've been using it for several days now. The issue is that it makes the Extension runtime in Nova a bit unstable, and gives you that error message every time you start the extension (usually only when you start the editor or open a new project).

have the ability to enter the "premium version" license code in the preferences

FWIW the preferences for extension should easily be able to handle that 🙂

What I'm mostly interested in adding is changing the stubs included when running Intelephense, which is what I plan to work on next, assuming I don't hear anything about this error.

@chipotle If you still have any of the feedback from @panicinc that you think might be useful here I'd be happy to take a look at it to see if that's something that can help address the issue, but like I said before; I really do think we need @bmewburn's input here.

[bmewburn]

@reykjalin , thanks for reporting this. I'll take a closer look when I can. The error is strange as intelephense does not dynamically register for workspace/didChangeWorkspaceFolders but instead declares support in the server capabilities returned from initialize.

LSP says:

The notification is sent by default if both client capability workspace.workspaceFolders and the server capability workspace.workspaceFolders.supported are true;

Maybe it is something in the node-language-server dependency.

if you have any issues with the extension itself being published, I can remove it. Likewise, if you want the extension to use a different name/icon/etc. I will respect those wishes.

This is fine with me as long as credit is given in the description/readme.

[reykjalin]

The error is strange as intelephense does not dynamically register for workspace/didChangeWorkspaceFolders but instead declares support in the server capabilities returned from initialize.

Hmm, then maybe the initialize method is doing something wrong in the Nova LSP client implementation. I'll try reaching out to Panic and see if they might now what's going on, or if they can help me debug this further.

Maybe it is something in the node-language-server dependency.

That would certainly be difficult to manage 😅. Since Intelephense isn't managing this manually, let's assume for now that the problem is in either Nova's client or the node-language-server dependency. I'll try to dig at this some more 🤔

This is fine with me as long as credit is given in the description/readme.

I'll make sure to add a statement in the extension's page giving you credit for Intelephense ☺️

[bmewburn]

Similar issue reported here microsoft/vscode-languageserver-node#713

[mjlbach]

We added a dummy callback to work around this neovim/nvim-lspconfig#471

We're running into similar issues with vscode-json-languageserver expecting dynamicRegistration/ignoring formatter initialization despite the documentation.

[reykjalin]

@bmewburn I see microsoft/vscode-languageserver-node#713 was addressed in microsoft/vscode-languageserver-node@5bc82ac which changed some things that will (hopefully) address the issue.

The release cycle for microsoft/vscode-language-server-node seems to be relatively slow so I don't think we'll see a release with the fix any time soon. Is there any chance I could somehow try a version of intelephense using microsoft/vscode-languageserver-node@5bc82ac or newer?

That way I could confirm whether that fixes the issue here instead of waiting several months to find out.

My wish would — of course — be to update the intelephense dependency to use the git commit, but I understand that will probably increase the maintenance burden on you, so I think that should be avoided if possible 🙂
Please let me know what you think when you have the time!

Thanks for your hard work on Intelephense!

[bmewburn]

@reykjalin I think it will need to wait. There's several packages in that repo with dependencies to each other and will take some effort to build and manage.

[reykjalin]

Ok, no problem! Thanks for taking the time to consider it ☺️

[reykjalin]

Hi again @bmewburn!

I just tried all the 1.6.x versions of Intelephense with Nova, and it seems that those versions are exhibiting a different issue; not sure if it's related.

Once started, Intelephense still throws the same error I reported above, but gets stuck indexing the files in the directory indefinitely. I'm not sure why, and I'm not sure how to debug the issue.

What would be the best way to get some logs so I can debug the issue further? I didn't see a documented way to do this with the initialization options or cli flags.

I can open a separate issue if you think this is caused by something new, and deserves it's own issue.

[bmewburn]

@reykjalin this might be something different. I think the debug logs I use are handled by the vscode-languageclient package so not applicable in this case. There's no debug mode within the server itself. Indexing is initialised on startup and uses the InitializeParams.rootUri or WorkspaceFolder.uri https://microsoft.github.io/language-server-protocol/specifications/specification-current/#initialize .

Either there is some file in the workspace that causes the extension to crash or it could be too many files in the workspace (current limit is 131072). I'm going to close this issue as in 1.7 the beta version of the next vscode-languageserver is used which should fix the original issue here. Feel free to open a new one specific to indexing.

[reykjalin]

All right, I'll wait for 1.7 and report back here. I'll wait to see if the indexing still hangs in 1.7 before opening another issue 🙂