-
Notifications
You must be signed in to change notification settings - Fork 138
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initialize request not handled with WebSocket connection #406
Comments
does vscode now have websocket support for language servers or did you come up with something custom? (in both cases do both send the same message format at monaco language client / ws jsonrpc does (e.g. regarding headers) here is a trace when using monaco
so any of these might be a good canidate |
I think they have but I'm connecting to Language Server which is not managed by VS Code. So the Language Server is launched outside of VS Code. The client part of VS Code is just connecting to this Language Server implementation. Thanks for the trace! |
so how does the client in your vscode plugin look like? |
the important part is:
EDIT: here is full branch of the client https://github.com/apupier/vscode-datavirt/tree/testLSPWebsocket-githubreference |
i am not sure if this will send the messages the websocket on server expects or if it will sent the header as well which then will break the json parsing see e.g. #189 |
interesting link. By following linke dissues, i came on one of your comment
My Language Server is using LSP4J 0.8.1 so I would expect that it is not hitting the issue. Or I misunderstood a part? And I still need to provide a specific implementation for MessageProducer/Consumer either on VS Code side or on Server side? |
no. the monaco language client does not send json rpc with header but the payload json only. |
I think that th eproblem is that VS COde is sending in Binary format although LSP4J does not provide a BinaryHandler: here is the stack that let me think that:
it is throwing the IllegalStateException in this piece of code:
|
so, this can be workarounded on client side by configuring it to use text format, for TypeScript, when using ws library, this can be done using
unfortunately it is still not working. The lsp4j MessageJSOnHandler is unable to read the incoming content:
|
and what is in the message? |
the content of the message is:
strange |
as i have said and is mentioned in that other issue: am not sure how https://github.com/TypeFox/vscode-ws-jsonrpc will behave |
asked on StaskOverflow how to avoid "CONTENT-LENGTH" with a Websocket connection: https://stackoverflow.com/questions/60372566/how-to-configure-websocket-to-not-send-content-length-in-javascript-typescript |
Just to chime in, we've been having the same issue once in a while as well. In our case, it happens in plain java JUnit tests so VS Code is not even in the loop. What we've seen is that the jsonRPC message is sometimes jumbled up for unknown reasons. This message can then of course not be interpreted by LSP4J. An example is shown below. As you can see somehow the Content-Length is sent separately as well as at the end of the initialize message ( Do note that this is for LSP4J <= 0.12.0
|
Sorry to resurrect this old issue but I have exact same problem. My LSP4J version is 0.21.0 and I cannot get it to work with VSCode LSP client. Wondering if anyone can give me any pointers on how to troubleshoot. Many thanks! E. |
is the header sent or not by vscode? |
@javaduke Are you getting the same stacktrace consistently? In our case this is a very rare occurence |
Well, I'm not getting an actual error, I just know that my |
Here's what I see on the server side:
|
Now, previously VSCode was sending frames in BINARY mode, I thought this could be an issue so I set the |
client and server just need to make sure they are on same if they send and expect content length WebSocketMessageHandler / WebSocketMessageConsumer i assume they dont expect the content length attribute |
It looks like the client does send the Content-Length, but the server still does not call initialize. Looks like it doesn't even reach the message handler, I set breakpoint at the JavaxWebSocketFrameHandler, it invokes |
no i mean other way round. |
Hmm, I don't have any WebSocketMessageHandler implementation, just to clarify, here's the relevant portion of my code:
It works with the Monaco client, so what am I missing here? |
cause monaco-language client does NOT wanna have /send the content length? the classes are hooked up at |
Sorry, I'm confused, looks like I'm doing it wrong, but is there any good example of how to do it right? |
i dont know the websocket feature is vscode so i cannot tell. can you provide a sample client extension.ts how this is setup in vscode? |
Like this:
|
and which of the two websocket flavours do you use? (also make sure you use the same in debugger) |
Sorry, don't understand your question, what do you mean by "two flavors"? Binary vs Text? That's what I suspect is an issue, the VSCode sends BINARY frames, whereas Monaco sends TEXT, and I'm wondering what should I do to make LSP4J accept and decode BINARY frames. |
there is two websocket packages in lsp4j |
I only see one,
What is the other one? |
org.eclipse.lsp4j.websocket.jakarta |
which WebSocket class are you using in client? |
On the server side I was using javax but I just tried switching to Jakarta and the problem is the same. In client I use the WebSocket class from the |
i dont know any interna of that package but cannot get this client conncting to my server |
Yes, and I believe the problem is still with the Content-Length header sent by the client. I don't see any way to disable this in client, so I'm wondering if it is possible somehow for LSP4j to understand or ignore this header. |
this is why i said to debug onMessage |
Yes, it fails before calling onMessage, but I cannot figure out what the issue is... |
OK, after further debugging here's what's going on. I set the breakpoint at the |
i assume you have to copy & paste subclass the class that calls the constructor. org.eclipse.lsp4j.websocket.WebSocketMessageHandler.WebSocketMessageHandler(MessageConsumer, MessageJsonHandler, MessageIssueHandler) but no more. |
See my sample code above, it's Jetty. |
i am still see |
Well, I tried to set decodeStrings to true in the client: |
which jsonHandler? |
|
i dont see this called at all. wonder how you setup jetty |
Nothing special about my jetty setup, I posted the code above: #406 (comment) |
Well, I tried everything I could and now I'm kinda stuck. I was able to successfully connect Monaco client to my LSP4J implementation, but not VSCode extension. |
Is there a reason / usecase you need to connect via web socket / process io or normal socket not an option |
Actually, no, normal socket would also be an option, but I'm not sure I know how to implement this in VSCode. |
Yep, thanks, with plain socket it works now. I will still need to solve the websocket problem though, but I can save this for later. |
Maybe also talk to vscode language client Team to introduce an option to configure if array is sent or plain text |
This subclass solution fixed the JSON-RPC header issue for me, but the backend LS I was using is implemented with pygls. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Currently trying to connect a VS Code Client to a Language Server written on LSP4J 0.8.1.
The "connect" method is called and it throws no error (when address is wrong, I have other errors)
The client is sending an initialize request:
But the implementation method LanguageServer.initialize(InitializeParams) is not called.
I tried to put breakpoint on org.eclipse.lsp4j.websocket.WebSocketMessageConsumer.consume(Message) and org.eclipse.lsp4j.websocket.WebSocketMessageHandler.onMessage(String) but these methods are not called either.
What is the best place to trace the request on Server side? so that i can see the path that it follows and see where the request is blocked/rejected/lost.
Please note that i was able to make it working with another client, Monaco.
The text was updated successfully, but these errors were encountered: