zed-industries/zed · warning · Error

GraphQL error: ${JSON.stringify(data.errors)}

Error message

GraphQL error: ${JSON.stringify(data.errors)}

What it means

Returned by Copilot::sign_out (copilot.rs:837) as a ready Err task for the catch-all arm of the server-state match. Only CopilotServer::Running (sends the SignOut LSP request) and CopilotServer::Disabled (no-op Ok at copilot.rs:836) are handled; Starting and Error both fall through to 'copilot hasn't started yet'. Note sign_out already called update_sign_in_status(NotSignedIn) before the match, so local sign-in state is cleared even though the server-side SignOut request cannot be sent.

Source

Thrown at script/get-release-notes-since:96

      method: "POST",
      headers: {
        Authorization: `Bearer ${GITHUB_ACCESS_TOKEN}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        query,
        variables: { owner: "zed-industries", repo: "zed", cursor },
      }),
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const data = await response.json();

    if (data.errors) {
      throw new Error(`GraphQL error: ${JSON.stringify(data.errors)}`);
    }

    if (!data.data || !data.data.repository || !data.data.repository.releases) {
      throw new Error(`Unexpected response structure: ${JSON.stringify(data)}`);
    }

    const releases = data.data.repository.releases.nodes;
    allReleases = allReleases.concat(releases);

    hasNextPage = data.data.repository.releases.pageInfo.hasNextPage;
    cursor = data.data.repository.releases.pageInfo.endCursor;

    lastReleaseOnPage = releases[releases.length - 1];

    if (
      releases.length > 0 &&
      new Date(lastReleaseOnPage.createdAt) < startDate
    ) {

View on GitHub (pinned to bc538def45)

Solutions

1. Treat it as benign when the goal is local sign-out: update_sign_in_status(NotSignedIn) already ran, so UI state is SignedOut; the token on the server side simply was not revoked.
2. If Starting, wait for status() to leave Status::Starting and call sign_out again so the SignOut request actually reaches the server.
3. If Error, fix or reinstall the server first, sign in, then sign out — or accept that the stale session remains authorized server-side.
4. Check status() is Status::Authorized/Unauthorized before calling sign_out to avoid the error entirely.

Example fix

// before
match copilot.sign_out(cx).await {
    Err(e) => log::error!("sign out failed: {e:#}"),
    _ => {}
}

// after: only attempt server-side sign-out on a live server
match copilot.status() {
    Status::Authorized | Status::Unauthorized | Status::SigningIn { .. } | Status::SignedOut { .. } => {
        copilot.sign_out(cx).await?;
    }
    _ => {
        // not running: local status already reset to NotSignedIn by sign_out itself
    }
}

// sign_out only meaningfully hits the LSP on a live server.
if matches!(copilot.status(), Status::Authorized | Status::Unauthorized | Status::SigningIn { .. }) {
    copilot.sign_out(cx).await?;
}
// otherwise: local status was already reset to NotSignedIn inside sign_out

fn can_sign_out(status: &Status) -> bool {
    matches!(
        status,
        Status::Authorized | Status::Unauthorized | Status::SigningIn { .. } | Status::SignedOut { .. }
    )
}

match copilot.sign_out(cx).await {
    Err(err) if format!("{err}").contains("hasn't started yet") => {
        // benign: local sign-out already applied; optionally retry once the start task finishes
    }
    Err(err) => return Err(err),
    Ok(()) => {}
}

When it happens

Trigger: Calling sign_out while the language server is still Starting (download/initialize in progress), or after it failed to start (CopilotServer::Error). The Running and Disabled states never produce this error.

Common situations: User signs out immediately after app launch while the npm package is still downloading; signing out right after a start failure; automated flows that call sign_out without checking status; double sign-out where the first attempt crashed the server.

Related errors

• Could not find UNIT_DATA in the file
• HTTP error! status: ${response.status}
• Failed to parse UNIT_DATA as JSON: ${e.message}
• Unexpected response structure: ${JSON.stringify(data)}
• Missing env var `ZED_SERVER_URL`

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