Testing small projects - sending data to goto_def example results in error

[Amar1729]

I'm a bit new to LSP programs and trying to test a small one sample right now. I'm running cargo run --example goto_def, but can't seem to figure out how to actually send commands to a stdio connection.

I saw pr #27 , and I've tried copying JSON-rpc commands and piping them to the command but neither seem to work properly:

$ cargo run --example goto_def

    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/examples/goto_def`
starting generic LSP server
{"jsonrpc":"2.0","method":"initialize","id":1,"params":{"capabilities":{}}}
Error: ProtocolError("expected initialize request, got error: receiving on an empty and disconnected channel")

$  cat send1                                                                     

{"jsonrpc":"2.0","method":"initialize","id":1,"params":{"capabilities":{}}}

$  cat send1|cargo run --example goto_def                                              

    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/examples/goto_def`
starting generic LSP server
Error: ProtocolError("expected initialize request, got error: receiving on an empty and disconnected channel")

$   cargo run --example goto_def < send1                                           

    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/examples/goto_def`
starting generic LSP server
Error: ProtocolError("expected initialize request, got error: receiving on an empty and disconnected channel")

I changed the sample to use sockets, but run into a different error here:

diff examples/goto_def.rs
-    let (connection, io_threads) = Connection::stdio();
+    let (connection, io_threads) = Connection::listen("127.0.0.1:5555")?;

$ cargo run                                                                         

    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/lumos-lsp`
starting generic LSP server
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidData, error: "malformed header: \"POST / HTTP/1.1\"" }', /Users/paula1/.cargo/registry/src/github.com-1ecc6299db9ec823/lsp-server-0.6.0/src/socket.rs:27:60
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: ProtocolError("expected initialize request, got error: receiving on an empty and disconnected channel")

# sent this curl cmd from a different tty during run
 $ curl -vv -XPOST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"initialize","id":1,"params":{"capabilities":{}}}' http://localhost:5555

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5555 (#0)
> POST / HTTP/1.1
> Host: localhost:5555
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 75
>
* upload completely sent off: 75 out of 75 bytes
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
* Closing connection 0

Am I missing something basic here about communication with the server?

[aldhsu]

I ran into the same issues. The function that is reading the requests msg.rs read_msg_txt only reads headers and that is why it fails at "POST / HTTP/1.1" since it is missing :. I put a continue in there if it runs into POST but then I'm back to the receiving on an empty and disconnected channel error.

Reading the code for Connection::initialize, it runs initialize_start which reads from receiver. initialize also runs initialize_finish which also reads from receiver this fails as soon it tries to read from the empty channel. Reading the instructions in the example I think this second receiver.recv() in the initialize_finish is supposed to be able to get the second message:

//! Content-Length: 59
//!
//! {"jsonrpc": "2.0", "method": "initialized", "params": {}}

For some reason it is not waiting on input and tries immediately to pull it off the receiver channel.

[wsw0108]

Under Windows?
I ran into the same issue under Windows, using python's subprocess.Popen(), Windows will inject/replace \r to message written to stdin...

For ref: https://docs.python.org/3/library/subprocess.html#frequently-used-arguments