zed-industries/zed · error

Request failed: {}

Error message

Request failed: {}

What it means

From Client::request<R> in the DAP client: the adapter answered a request with a Response whose success flag is false, and the bail interpolates response.message (empty string when the adapter omits it, due to unwrap_or_default). Per the Debug Adapter Protocol, this is the adapter's structured way to reject a request - launch/attach failures, invalid arguments, unsupported commands.

Source

Thrown at crates/dap/src/client.rs:152

            sequence_id
        );
        log::debug!("  response: {response:?}");

        match response.success {
            true => {
                if let Some(json) = response.body {
                    Ok(serde_json::from_value(json)?)
                // Note: dap types configure themselves to return `None` when an empty object is received,
                // which then fails here...
                } else if let Ok(result) =
                    serde_json::from_value(serde_json::Value::Object(Default::default()))
                {
                    Ok(result)
                } else {
                    Ok(serde_json::from_value(Default::default())?)
                }
            }
            false => anyhow::bail!("Request failed: {}", response.message.unwrap_or_default()),
        }
    }

    pub async fn send_message(&self, message: Message) -> Result<()> {
        self.transport_delegate.send_message(message).await
    }

    pub fn id(&self) -> SessionId {
        self.id
    }

    pub fn binary(&self) -> &DebugAdapterBinary {
        &self.binary
    }

    /// Get the next sequence id to be used in a request
    pub fn next_sequence_id(&self) -> u64 {
        self.sequence_count.fetch_add(1, Ordering::Relaxed)

View on GitHub (pinned to f4178619ac)

Solutions

1. Check the request that preceded it in Zed's DAP log (request/response pairs are debug-logged) and fix its arguments
2. Verify program/paths are absolute or resolvable from the adapter's cwd
3. Confirm the debuggee is still running before issuing evaluate/variables requests
4. For an empty message, enable adapter logging to see the response body - the adapter omitted the message field

Example fix

// before
let caps = client.request::<InitializeRequest>(args).await?;

// after: surface the adapter's message instead of an opaque error
let caps = match client.request::<InitializeRequest>(args).await {
    Ok(caps) => caps,
    Err(err) => {
        log::warn!("initialize rejected by adapter: {err:#}");
        return Err(err.context("adapter rejected initialize; check adapter path and arguments"));
    }
};

// Validate the program path before launching through the adapter
if let Some(program) = &launch_args.program {
    anyhow::ensure!(program.exists(), "program path does not exist: {program:?}");
}

match client.request::<LaunchRequest>(args).await {
    Ok(_) => { /* proceed to configurationDone */ }
    Err(err) => {
        // err message is the adapter's own reason, or empty when omitted
        return Err(err.context("launch rejected by adapter; verify program/args/cwd"));
    }
}

When it happens

Trigger: Any client.request::<R>(args) call where the adapter replies success=false: LaunchRequest with a nonexistent program path, AttachRequest with a bad PID/port, SetBreakpointsRequest with unresolvable locations, EvaluateRequest after the debuggee terminated, or any request the adapter does not support. Adapters that set success=false without a message yield the bare 'Request failed: ' string.

Common situations: Wrong 'program' path in launch.json/debug config; adapters whose working directory differs so relative paths fail; requests issued after the session ended; adapter-specific argument schema mismatches after an adapter upgrade.

Related errors

• Received error response from adapter. Response: {:?}
• Timed out when connecting to debugger
• Connection to TCP DAP timeout {address}
• {output} error: process exited before debugger attached.
• When using the `stdio` transport, the path to a debug adapte

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