What causes "Received error response from adapter. Response: {:?}" in zed-industries/zed?

Inspect the {:?} Response dump - the request seq and body carry the real cause

Received error response from adapter. Response: {:?}

Error message

Received error response from adapter. Response: {:?}

What it means

Fallback bail inside process_response: the adapter sent success=false, but neither body (parsed as ErrorResponse).error.format nor response.message yielded usable text, so Zed dumps the entire serialized Response with {:?}. It exists to guarantee every failed request produces an error even when the adapter omits both message and structured error body.

Source

Thrown at crates/dap/src/transport.rs:384

        result
    }

    fn process_response(response: Response) -> Result<Response> {
        if response.success {
            Ok(response)
        } else {
            if let Some(error_message) = response
                .body
                .clone()
                .and_then(|body| serde_json::from_value::<ErrorResponse>(body).ok())
                .and_then(|response| response.error.map(|msg| msg.format))
                .or_else(|| response.message.clone())
            {
                anyhow::bail!(error_message);
            };

            anyhow::bail!(
                "Received error response from adapter. Response: {:?}",
                response
            );
        }
    }

    async fn receive_server_message<Stdout>(
        reader: &mut BufReader<Stdout>,
        buffer: &mut String,
        log_handlers: Option<&LogHandlers>,
    ) -> ConnectionResult<Message>
    where
        Stdout: AsyncRead + Unpin + Send + 'static,
    {
        let mut content_length = None;
        loop {
            buffer.clear();
            match reader.read_line(buffer).await {

View on GitHub (pinned to f4178619ac)

Solutions

Inspect the {:?} Response dump - the request seq and body carry the real cause
Check the adapter's DAP conformance; file an issue so it sets message or error.format
Reproduce the failing request against the adapter directly to see its raw response

Defensive patterns

Strategy: try-catch

Try / catch

match client.request::<SetBreakpointsRequest>(args).await {
    Ok(resp) => Ok(resp),
    Err(err) => {
        // message contains the full {:?} Response dump when the adapter omitted error text
        log::warn!("adapter rejected request: {err:#}");
        Err(err)
    }
}

Prevention

When writing a custom adapter, always set message or error.format on failed responses
Parse the debug-formatted Response in the error for request_seq to correlate with the failed call

When it happens

Trigger: An adapter replies success=false with an empty/missing message and a body that does not deserialize into ErrorResponse's error.format shape - minimal or non-compliant adapters, codelldb/delve variants that return id/naming the failure differently, or bodies whose error object uses a non-string format.

Common situations: Third-party or custom DAP adapters with loose conformance; adapters that report errors only via show-message events rather than the response; upgrading an adapter changes its error body schema.

Related errors

AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/ebc6899b383bdc6d. Report an issue: GitHub.