Will calls on `ServerSocket::request` returned `MainLoop::new_client` applies Tower layers?

[alissa-tung]

Thank you for developing this library, and

Hello, I had tried two ways creating Tower layers to make some logs:

• the first approach is to simple create a Tower layer, logging on trait methods fn notify, fn emit and fn call
• the second approach is enable the forward feature, mock the server and client like what examples/interceptor.rs do, logging on trait methods fn notify, fn emit and fn call

both approach applies logs for requests from server to client, but does not work for the requests that I filed from client with ServerSocket::request, where the ServerSocket instance is returned by MainLoop::new_client.

My questions are:

• will calls on ServerSocket::request returned MainLoop::new_client applies Tower layers?
• did I miss something or some methods when logging on trait methods fn notify, fn emit and fn call
• what is the event in the library?

I had also tried to use the builder function MainLoop::new_client's server socket argument, use router.request::<ACustomRequest>(|router_state, request| { logging here; return here }). but

• I do not know that does the parameter server socket of the MainLoop::new_client do
• the logging seems in the .request::<MainLoop::new_client>(....) does not work, the callback is not fired
• in the .request::<MainLoop::new_client>(....) callback, calling the .request of server_socket yields the Result<_, async_lsp:Error>, but not the Result<_, async_lsp:ResponseError> which is required by the router.request callback

[oxalica]

• will calls on ServerSocket::request returned MainLoop::new_client applies Tower layers?
• did I miss something or some methods when logging on trait methods fn notify, fn emit and fn call

Unfortunately, no at least for now. It will enqueue the message and send it to the peer directly without extra handlers. You can wrap the *Socket to do that though that will change the type.

I think Tower layers are mainly used to modular services construction, so the local connection API *Socket does not apply. We can wrap tower layers on it, but I don't know how useful it is besides for logging purpose. Also the delay you measured on *Socket::request would be your protocol peer's handling delay, which is outside your control.

• what is the event in the library?

It is mentioned in LspService::emit. It's a custom message passing method to do stuff synchronously in the main loop, or trigger specific works in the main loop from other threads. Eg. trigger server exit on some conditions maybe from another thread (used by client_monitor here), diagnostic refresh after some delay (timer tick event example here), and etc. Since the event handling is always executed synchronously in the main thread, you can use &mut self without locking and don't need to tangle with async-request reordering.