clockworklabs/SpacetimeDB · error · anyhow::Error

Failed to check client process status: {}

Error message

Failed to check client process status: {}

What it means

The fail-fast check after starting the dev client calls `try_wait()`; if that OS-level call itself returns `Err` (rather than an exit status), the CLI bails with the underlying error. This is an infrastructure failure of process introspection — on Unix typically ECHILD/EINVAL from waitpid (e.g. the child was already reaped by something else) — not a normal client crash.

Source

Thrown at crates/cli/src/subcommands/dev.rs:809

    let server_host_url = config.get_host_url(Some(server_for_client))?;
    let mut client_handle = if let Some(ref cmd) = client_command {
        let mut child = start_client_process(cmd, &project_dir, db_name_for_client, &server_host_url)?;

        // Give the process a moment to fail fast (e.g., command not found, missing deps)
        sleep(Duration::from_millis(200)).await;
        match child.try_wait() {
            Ok(Some(status)) if !status.success() => {
                anyhow::bail!(
                    "Client command '{}' failed immediately with exit code: {}",
                    cmd,
                    status
                        .code()
                        .map(|c| c.to_string())
                        .unwrap_or_else(|| "unknown".to_string())
                );
            }
            Err(e) => {
                anyhow::bail!("Failed to check client process status: {}", e);
            }
            _ => {} // Still running or exited successfully (unusual but ok)
        }
        Some(child)
    } else {
        None
    };

    let gitignore = build_gitignore_matcher(&project_dir, &spacetimedb_dir);

    let (tx, rx) = channel();
    let mut watcher: RecommendedWatcher = Watcher::new(
        move |res: Result<Event, notify::Error>| {
            if let Ok(event) = res
                && matches!(
                    event.kind,
                    notify::EventKind::Modify(_) | notify::EventKind::Create(_) | notify::EventKind::Remove(_)
                )

View on GitHub (pinned to 524b4487d9)

Solutions

1. Retry `spacetime dev` — races like this are transient
2. Run the client command outside the dev loop to confirm it works standalone
3. If in a container, run with a proper init (docker `--init`) and standard signal handling
4. Report with the appended OS error text if it reproduces consistently

// On 'Failed to check client process status', treat as transient: tear down the dev loop and restart it once; escalate only if the appended OS error repeats.

When it happens

Trigger: The child process being reaped by a signal handler or a wrapper that double-waits; PID namespace / container quirks (docker, sandboxed CI) breaking waitpid; extremely unusual process teardown racing the 200ms check.

Common situations: Running `spacetime dev` inside minimal containers or devcontainers with custom init processes; client commands launched through shell wrappers that forward or detach signals.

Related errors

• Client command '{}' failed immediately with exit code: {}
• Unsupported --dotnet-version {version}. Supported values: 8,
• No such saved server configuration: {server} Add a new serve
• No default server configuration. Set an existing server as t
• Server nickname {} already in use: {}://{}

AI-assisted analysis of clockworklabs/SpacetimeDB@524b4487d9 (2026-08-16). Data as JSON: /api/errors/1a4cbe009d7cf57d. Report an issue: GitHub.