clockworklabs/SpacetimeDB · error · anyhow::Error

Pre-publish check failed with status

Error message

Pre-publish check failed with status {}: {}

What it means

Every publish to an existing database first POSTs the module bytes to the pre-publish (schema-diff) endpoint. A 404 is tolerated (it means new database, no breaking changes); any other non-success status bails here with the HTTP status code and the raw response body embedded in the message.

Solutions

  1. Read the embedded status and body: 401/403 means re-run `spacetime login`; a panic/stack trace means inspect the server logs.
  2. Check connectivity and version pairing: `spacetime server ping`, and update the standalone server (`spacetime start`/server update) or the CLI so they match.
  3. Retry once after a short delay for transient 5xx or network blips.
  4. If a proxy is involved, verify it forwards the request with the full body (the module bytes are sent as the request body).
Defensive patterns

Strategy: retry

Validate before calling

# Pre-flight before publishing
spacetime server ping "$SERVER" || exit 1
spacetime login >/dev/null 2>&1 || true   # refresh credentials if they may be stale

Try / catch

for attempt in 1 2 3; do
  out=$(spacetime publish mydb 2>&1); status=$?
  [ $status -eq 0 ] && break
  echo "$out" | grep -q "Pre-publish check failed with status 5" || { echo "$out"; exit 1; }
  sleep $((attempt * 5))
done

Prevention

When it happens

Trigger: `spacetime publish` where the pre-publish HTTP call returns 401/403 (expired or invalid token), 400 (malformed identity or request), 5xx (server-side failure), or an error page from a proxy/load balancer sitting in front of the server.

Common situations: Token expired or from a different server; CLI newer than a self-hosted standalone server that lacks or changed the pre-publish route (version skew); reverse proxies returning HTML error pages; database left in a bad state after a crashed publish (check server logs).

Related errors


AI-assisted analysis of clockworklabs/SpacetimeDB@eddf9f5014 (2026-08-20). Data as JSON: /api/errors/429af77df07deca8. Report an issue: GitHub.

Appendix: source

Thrown at crates/cli/src/subcommands/publish.rs:992

) -> Result<Option<PrePublishResult>, anyhow::Error> {
    let mut builder = client.post(format!("{database_host}/v1/database/{domain}/pre_publish"));
    let style: PrettyPrintStyle = pretty_print_style_from_env();
    builder = builder
        .query(&[("pretty_print_style", style)])
        .query(&[("host_type", host_type)]);

    builder = add_auth_header_opt(builder, auth_header);

    println!("Checking for breaking changes...");
    let res = builder.body(program_bytes.to_vec()).send().await?;

    if res.status() == StatusCode::NOT_FOUND {
        // This is a new database, so there are no breaking changes
        return Ok(None);
    }

    if !res.status().is_success() {
        anyhow::bail!(
            "Pre-publish check failed with status {}: {}",
            res.status(),
            res.text().await?
        );
    }

    let pre_publish_result: PrePublishResult = res.json_or_error().await?;
    Ok(Some(pre_publish_result))
}

#[cfg(test)]
mod tests {
    use pretty_assertions::assert_matches;
    use spacetimedb_lib::Identity;
    use std::collections::HashMap;

    use super::*;

View on GitHub (pinned to eddf9f5014)