hi @lukaszsamson
I am unable to create a new repo that reproduces the problem. I should mention that all my other elixir repos can run ElixirLS successfully (except for one, totaling 2 repos that don’t work). I cannot discern significant differences between them that would hint at the problem currently.
But I am able to get ElixirLS to work on both repos when I lower the version to 0.17.3 !!!
Anything beyond that does not work.
I can reproduce your crash on windows only. The repo works fine on macos. The language server is not crashing, it’s vscode that closes the connection. It looks like another wonderful case od OTP 26 breaking basic stdio like other ones in Not starting on OTP26 · Issue #886 · elixir-lsp/elixir-ls · GitHub
Thanks for diving in and figuring it out, especially so quickly! Too bad the issue is in OTP itself.
It sounds like if I roll back to using OTP 25 that everything should be working? That’s easy enough for me to do since I’m not using any OTP 26 specific features, that I know of, in any projects at the moment.
I haven’t tested on OTP 25. I opened Language server stops working on windows OTP 26 · Issue #1023 · elixir-lsp/elixir-ls · GitHub for tracking. It seems the issue is caused by message truncation. It can be triggered with completion on empty string when there’s many options. Completions starting from some prefix work fine
Thanks for filing the ticket.
Also, I rolled back to OTP 25, and everything seems to be working again as expected. 
So that’s good that it seems to be only in OTP 26, for Windows at least.
I’m experiencing this with OTP 25 on MacOS Ventura 13.5 M1 Max Chipset as well:
Erlang/OTP 25 [erts-13.1.5] [source] [64-bit]
Please be more specific. Do you mean the OTP error? or something else. Do you have a rep that reproduces it?
The culprit was on my end. The LS wasn’t able to build due to dependency conflicts in my umbrella application and was resulting in the same “Unable to find formatter” error. Apologies for the unrelated alarm. Though the symptoms were the same
I need to improve the experience on that front. The build can fail for hundreds of reasons and asking the user to run mix deps.get on every failure would be misleading