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.

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)

Solutions

1. Check rust-analyzer's logs (RA_LOG / editor output channel) for the panic message and backtrace to find the offending task.
2. Update rust-analyzer to the latest release; many task panics are fixed bugs.
3. Reduce the trigger: identify which request/file caused the panic and minimize or avoid it, then file an issue.
4. Restart the language server; the panic is terminal for this server instance.
5. As a last resort, clear target/ caches (`cargo clean`, delete `target/`) if the panic stems from corrupted cached state.

Example fix

null

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),
}

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

• Unable to convert to an AbsPath
• Unable to serialize data
• Unable to write data
• not a BlockExpr
• this node should have an ast id

AI-assisted analysis of rust-lang/rust-analyzer@e8f7e90aa3 (2026-09-03). Data as JSON: /api/errors/6e1152b1f1aa493e. Report an issue: GitHub.