You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider this scenario: we are invoking a request,
client.send_request::<MyRequest>(params).await?;
but the future that awaits it is getting cancelled and therefore the receiving end of the channel is getting dropped. Currently this would cause a panic with the "receiver already dropped" message. I believe it's coming from here:
tx.send(r).expect("receiver already dropped");
This is quite common situation and it feels like this code should not panic. Can the send error be safely ignored instead?
The text was updated successfully, but these errors were encountered:
I'm currently hitting this issue with a textDocument/diagnostics event.
For a typical file, my server responds to this request in a few hundred microseconds. However, if I type as fast as my keyboard allows me in the document, eventually one of these requests will not complete in time for the client to cancel a previous one.
It panics with the above on trying to send the result on a closed channel.
I can submit a fix if this isn't on anyone's radar.
Consider this scenario: we are invoking a request,
but the future that awaits it is getting cancelled and therefore the receiving end of the channel is getting dropped. Currently this would cause a panic with the "receiver already dropped" message. I believe it's coming from here:
This is quite common situation and it feels like this code should not panic. Can the
send
error be safely ignored instead?The text was updated successfully, but these errors were encountered: