Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic on future cancellation #417

Open
s-panferov opened this issue Apr 29, 2024 · 2 comments
Open

Panic on future cancellation #417

s-panferov opened this issue Apr 29, 2024 · 2 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@s-panferov
Copy link

s-panferov commented Apr 29, 2024

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?

@ebkalderon
Copy link
Owner

I think that's reasonable enough. The code could simply be changed to swallow the Result with a simple let _ = assignment and not expecting on it.

@ebkalderon ebkalderon added enhancement New feature or request good first issue Good for newcomers labels Apr 29, 2024
@peterhuene
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants