zed-industries/zed · warning

Feedback API returned status: {}

Error message

Feedback API returned status: {}

What it means

Telemetry for accept/reject feedback on predictions: after POSTing the user action to the feedback API, a non-success status bails with the status code (mercury.rs:474). The whole task is spawned detached with `detach_and_log_err`, so the error only ever appears in logs and never affects editing or predictions.

Source

Thrown at crates/edit_prediction/src/mercury.rs:474

    let request_id = prediction_id.0;
    let app_version = AppVersion::global(cx);
    cx.background_spawn(async move {
        let body = FeedbackRequest {
            request_id,
            provider_name: "zed",
            user_action: action,
            provider_version: app_version.to_string(),
        };

        let request = http_client::Request::builder()
            .uri(FEEDBACK_API_URL)
            .method(Method::POST)
            .header("Content-Type", "application/json")
            .body(AsyncBody::from(serde_json::to_vec(&body)?))?;

        let response = http_client.send(request).await?;
        if !response.status().is_success() {
            anyhow::bail!("Feedback API returned status: {}", response.status());
        }

        log::debug!(
            "Mercury feedback sent: request_id={}, action={:?}",
            body.request_id,
            body.user_action
        );

        anyhow::Ok(())
    })
    .detach_and_log_err(cx);
}

View on GitHub (pinned to f4178619ac)

Solutions

1. No user action required for normal editing; feedback loss is harmless.
2. If it persists in logs, verify sign-in state and network access to the feedback endpoint.
3. Ignore isolated occurrences during known Zed service incidents.

Keep the fire-and-forget shape: `spawn(...).detach_and_log_err(cx)` — catch, log at debug/warn with the status, and drop; never surface feedback failures to the editing UI.

When it happens

Trigger: The feedback POST returning 4xx/5xx — bad/expired token, endpoint temporarily down, or a proxy blocking the POST — fired in the background right after a prediction is accepted or rejected.

Common situations: Transient backend errors during incidents; tokens expiring mid-session; restrictive networks. Users normally never see this; it surfaces when inspecting logs.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

• Request failed with status: {:?} Body: {}
• missing Content-Type header
• Failed to fetch experiments: {:?} Body: {}
• Request failed with status: {status:?} Body: {body}
• failed to fetch '{url}': status code {}

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