fix: properly log when engine fails to initialize

[badosu]

Previously whenever there was some error initializing the project node a few things would happen:

• The node supervisor start code would fail with match error
• The server would shutdown via init_timeout
• There would be no indication as to the reason, except reading the node message debug message in expert.log

Now:

• We properly respond to an initialize request with a server not initialized error
• We gracefully shut down the node processes
• We send an error message to the client with the last message sent by the node:

Node exited with status 127, last message: /home/badosu/.local/share/mise/installs/elixir/1.18.4-otp-26/bin/elixir: line 244: exec: erl: not found

This PR is motivated as an attempt to mitigate one of the many situations where expert fails silently, e.g.: #241

Remarks

• We additionally remove code related to waiting for didChangeConfiguration since it was noop

[mhanberg]

instead, lets put an info log in the 0 clause of the case, saying the engine shutdown

then in the error clause, put an error log saying it shutdown unexpectedly

[mhanberg]

there are helpers to in GenLSP already for starting the server with the tcp adapter.

[badosu]

Yeah, but they start the server individually whereas Expert requires its own constellation of other servers available to operate (hence why we started as an application).

[badosu]

For now I just removed the full expert server test as I'm not fully confident it will work reliably (the application might already have been started on another test). I might send as a separate PR, let me know your thoughts.

As for using GenLSP.Test.server we'd require allowing it to receive options suitable for our server, for example see buffer initialization hardcoded.

[badosu]

I reintroduced full server testing with a different approach.

And removed it again, it seems to not work as well regardless of the approach, might be better suited on a separate PR.

[mhanberg]

As for using GenLSP.Test.server we'd require allowing it to receive options suitable for our server, for example see buffer initialization hardcoded.

I don't really understand what you are meaning here.

With the GenLSP test sdk, we should be able to start individual expert server instances and test them in isolation. I did it for basically every test in Next LS.

I think there are some small changes to make to make that possible as it stands right now, but can be accomplished later on.

[badosu]

As for using GenLSP.Test.server we'd require allowing it to receive options suitable for our server, for example see buffer initialization hardcoded.

I don't really understand what you are meaning here.

For example, our application starts our genlsp buffer with a name and specific opts: {GenLSP.Buffer, [name: Expert.Buffer] ++ buffer_opts}. Maybe I'm missing something, but this is moot until I can make the full server test reliable anyway.

I think there are some small changes to make to make that possible as it stands right now, but can be accomplished later on.

Happy to hear if they seem straightforward enough.

[mhanberg]

For example, our application starts our genlsp buffer with a name and specific opts: {GenLSP.Buffer, [name: Expert.Buffer] ++ buffer_opts}. Maybe I'm missing something, but this is moot until I can make the full server test reliable anyway.

The idea is you don't start/utilize the application, you start an instance of the server per test, each has their own buffer and tcp connection to ensure isolation.

When you start the server with the server/2 function in the GenLSP test sdk, it starts a buffer and passes it to the options of your lsp process. The one started in the application supervision tree doesn't really matter.

You can see more [https://github.com/elixir-tools/next-ls/blob/main/test/support/utils.ex#L67]

we can look into this later, tho.

[badosu]

The idea is you don't start/utilize the application, you start an instance of the server per test, each has their own buffer and tcp connection to ensure isolation.

Oh, I completely understand that. In fact I had this iteration and one based on that that didn't start particularly Expert instead using GenLSP.Test.server.

The problem is that for now it seems to me that the implementation of GenLSP.Test.server itself does a few things I'd rather have it not, or at least accept options for those. You can see for example the kind of child_spec I'd want for it to be able to initialize instead here.

We can also vendor it ourselves anyway so this is not a big deal, or maybe even having the special names don't cause any issues.

Again this is a bit moot right now anyway so I won't digress further into it.

[mhanberg]

Again this is a bit moot right now anyway so I won't digress further into it.

Discussion is fine, its great to get feedback

We can also vendor it ourselves anyway so this is not a big deal,

I'm the author of GenLSP. We can change it however we want.

The problem is that for now it seems to me that the implementation of GenLSP.Test.server itself does a few things I'd rather have it not, or at least accept options for those. You can see for example the kind of child_spec I'd want for it to be able to initialize instead here.

I'm not really following this. It overrides the assigns, buffer, and task queue but passes through any other options.

Those 3 processes should be opaque to the consumer, so you really shouldn't be reading into them from a test anyway, but they are also available from in the return value from the server function.

Why might you want to start those yourself?

[badosu]

Why might you want to start those yourself?

There might be a circumstance in which the name is explicitly used, for example at least once we explicitly use the :expert_task_supervisor name.

If you assess all is good then all is good 👍

[mhanberg]

Add the root_uri here as well and any other log about the engine

[badosu]

I added the project as a prefix but I'm not sure that's desired in the current incarnation. Let me know if this message format looks good to you.