What causes "snowflake sql api timed out code={} message={}" in zed-industries/zed?

Reduce the query scope (shorter time window / fewer examples per run) so the statement finishes within the timeout

snowflake sql api timed out code={} message={}

Error message

snowflake sql api timed out code={} message={}

What it means

Raised when the Snowflake SQL API response is a timeout: is_timeout_response (pull_examples.rs:2063) matches a body whose code is '000630' AND whose message contains 'timeout' (case-insensitive). This is Snowflake reporting that the statement exceeded its execution timeout (STATEMENT_TIMEOUT_IN_SECONDS) or the request-level timeout — the statement is still 'executing' from the API's view, so no rows are returned. The crate keeps a companion helper is_snowflake_timeout_error for classifying these in downstream retry logic, signalling they are expected and often retryable.

Source

Thrown at crates/edit_prediction_cli/src/pull_examples.rs:545

        let mut body = response.into_body();
        let mut bytes = Vec::new();
        body.read_to_end(&mut bytes)
            .await
            .context("failed to read Snowflake SQL API response body")?;
        bytes
    };

    let snowflake_response = serde_json::from_slice::<SnowflakeStatementResponse>(&body_bytes)
        .context("failed to parse Snowflake SQL API response JSON")?;

    if !status.is_success() && status.as_u16() != 202 && !is_timeout_response(&snowflake_response) {
        let body_text = String::from_utf8_lossy(&body_bytes);
        anyhow::bail!("snowflake sql api http {}: {}", status.as_u16(), body_text);
    }

    if is_timeout_response(&snowflake_response) {
        anyhow::bail!(
            "snowflake sql api timed out code={} message={}",
            snowflake_response.code.as_deref().unwrap_or("<no code>"),
            snowflake_response
                .message
                .as_deref()
                .unwrap_or("<no message>")
        );
    }

    Ok(snowflake_response)
}

pub async fn fetch_rejected_examples_after(
    http_client: Arc<dyn HttpClient>,
    after_timestamps: &[(bool, String)],
    max_rows_per_timestamp: Option<usize>,
    offset: usize,
    background_executor: BackgroundExecutor,

View on GitHub (pinned to f4178619ac)

Solutions

Reduce the query scope (shorter time window / fewer examples per run) so the statement finishes within the timeout
Raise the timeout, e.g. ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 3600, or use a larger warehouse for the pull
Re-run: the code classifies timeout errors as retryable (is_snowflake_timeout_error), and pulls resume from what was already fetched

Example fix

-- before
SELECT ... FROM examples WHERE ts > '2026-01-01'; -- huge range, times out (000630)

-- after
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 7200;
SELECT ... FROM examples WHERE ts BETWEEN '2026-07-01' AND '2026-07-15';

Defensive patterns

Strategy: retry

Try / catch

match fetch_examples(&state).await {
    Err(e) if is_snowflake_timeout_error(&e) => {
        // statement hit its execution timeout; shrink the window and retry
        state.shrink_time_window();
        fetch_examples(&state).await?
    }
    other => other?,
}

Prevention

Size pulls to finish under STATEMENT_TIMEOUT_IN_SECONDS, or raise the timeout for known-large queries
Reuse the crate's is_snowflake_timeout_error classifier to route 000630 timeouts into retry logic
Prefer smaller time-windowed pulls over one giant statement; they resume cleanly on retry

When it happens

Trigger: Running a pull-examples query (rated/requested/settled/captured/rejected) over a large time window so the statement runs longer than the configured timeout; the HTTP call succeeds but the parsed response body carries code=000630 with a timeout message instead of data.

Common situations: Growing datasets making previously-fine queries exceed STATEMENT_TIMEOUT_IN_SECONDS; warehouse size downgraded so the same query takes longer; ad-hoc wide date-range pulls.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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