rust-lang/rust-analyzer · critical · anyhow::Error
A receiver has been dropped, something panicked!
Error message
A receiver has been dropped, something panicked!
What it means
The main loop's `run` drives the event loop until either the connection closes (returns `Ok(())`) or, upon exiting the loop for any other reason, returns `Err("A receiver has been dropped, something panicked!")`. This signals that a task/thread owned by the server (e.g. a task pool worker or queue task holding the other end of the crossbeam channel) panicked or was dropped, so the event loop can no longer make progress.
Solutions
- Check rust-analyzer's logs (RA_LOG / editor output channel) for the panic message and backtrace to find the offending task.
- Update rust-analyzer to the latest release; many task panics are fixed bugs.
- Reduce the trigger: identify which request/file caused the panic and minimize or avoid it, then file an issue.
- Restart the language server; the panic is terminal for this server instance.
- As a last resort, clear target/ caches (`cargo clean`, delete `target/`) if the panic stems from corrupted cached state.
Example fix
null
Defensive patterns
Strategy: try-catch
Try / catch
match rust_analyzer::run(server) {
Ok(()) => {}
Err(e) if e.to_string().contains("receiver has been dropped") => {
// a worker task panicked; log the captured panic, then restart the server process
tracing::error!("internal task panicked: {e:#}"),
restart_server_with_backoff();
}
Err(e) => return Err(e),
} Prevention
- Keep rust-analyzer updated; task panics are fixed continuously.
- Run with RA_LOG env tracing enabled so the panicking task is identifiable.
- Avoid unrelease-toolchain mismatches that can panic workspace-loading tasks.
- Supervise the LSP process (editor restart-on-crash settings) so a panic doesn't kill the whole session.
When it happens
Trigger: An internal task panicking (e.g. a `thread::spawn`ed task or a pool task handling a request dies), causing the sender side of the main-loop event channel to drop and the loop's recv/dispatch path to terminate abnormally rather than with a clean shutdown notification.
Common situations: Bug-triggered panics inside task handlers while processing a particular request; OOM or panics in workspace loading threads; running a broken/nightly-only server binary against unexpected inputs.
Related errors
- no block
- not a BlockExpr
- this node should have an ast id
- Unable to convert to an AbsPath
- Unable to serialize data
AI-assisted analysis of rust-lang/rust-analyzer@e8f7e90aa3 (2026-09-03).
Data as JSON: /api/errors/6e1152b1f1aa493e.
Report an issue: GitHub.
Appendix: source
Thrown at crates/rust-analyzer/src/main_loop.rs:217
self.fetch_workspaces(cause, path, force_crate_graph_reload);
}
}
while let Ok(event) = self.next_event(&inbox) {
let Some(event) = event else {
anyhow::bail!("client exited without proper shutdown sequence");
};
if matches!(
&event,
Event::Lsp(lsp_server::Message::Notification(Notification { method, .. }))
if method == lsp_types::ExitNotification::METHOD.as_str()
) {
return Ok(());
}
self.handle_event(event);
}
Err(anyhow::anyhow!("A receiver has been dropped, something panicked!"))
}
fn register_did_save_capability(&mut self, additional_patterns: impl Iterator<Item = String>) {
let additional_filters = additional_patterns.map(|pattern| {
lsp_types::DocumentFilter::TextDocumentFilter(lsp_types::TextDocumentFilter::Pattern(
lsp_types::TextDocumentFilterPattern {
language: None,
scheme: None,
pattern: pattern.into(),
},
))
});
let mut selectors = vec![
lsp_types::DocumentFilter::TextDocumentFilter(lsp_types::TextDocumentFilter::Pattern(
lsp_types::TextDocumentFilterPattern {
language: None,
scheme: None,View on GitHub (pinned to e8f7e90aa3)