xai-org/grok-build · critical

bridge spawn

Error message

bridge spawn

What it means

Panic raised when spawning the ACP bridge in the leader-cluster client setup fails — the underlying spawn/connect call returned an Err and `.expect("bridge spawn")` converts it into a panic. This means the pager could not establish the leader bridge channel (task spawn, handshake transport setup, or channel creation failed).

Source

Thrown at crates/codegen/xai-grok-pager/src/app/leader_cluster/mod.rs:445

                LeaderClientCapabilities {
                    client_version: Some("0.0.0-test".to_string()),
                    ..Default::default()
                },
                status_tx,
            );
            (Some(reconnector), Some(status_rx))
        } else {
            (None, None)
        };

        let bridge = bridge_channels(
            leader_tx,
            leader_rx,
            cancel.clone(),
            reconnector,
            ReconnectPolicy::unbounded(),
        )
        .expect("bridge spawn");
        let tx = bridge.channel.tx;
        let rx = bridge.channel.rx;

        // Same handshake the pager performs after bridging (spawn path).
        let _init: acp::InitializeResponse = bounded(
            "initialize",
            acp_send(
                acp::InitializeRequest::new(acp::ProtocolVersion::V1)
                    .client_capabilities(
                        acp::ClientCapabilities::new()
                            .fs(acp::FileSystemCapabilities::new())
                            .terminal(false),
                    )
                    .meta(
                        serde_json::json!({
                            "startupHints": {
                                "nonInteractive": true,
                                "skipGitStatus": true,

View on GitHub (pinned to bc7f02eddd)

Solutions

1. Read the underlying Err from the panic payload — it names whether spawn or connect failed.
2. Ensure setup runs inside an active tokio runtime (not from a blocking context or after runtime shutdown).
3. Check the leader process/endpoint is alive and reachable before bridging.
4. Handle the error gracefully instead of expect: return a client-setup Result so leader mode can degrade.

Example fix

// before
.expect("bridge spawn");
// after
let bridge = bridge(...).map_err(|e| ClientError::BridgeSpawn(e.to_string()))?;

// ensure we're inside a tokio runtime before spawning the bridge
assert!(tokio::runtime::Handle::try_current().is_ok(), "bridge spawn requires a tokio runtime");

match bridge(...args) {
    Ok(b) => b,
    Err(e) => return Err(ClientError::BridgeSpawn(e.to_string())),
}

When it happens

Trigger: `bridge(...)` returning Err during leader-mode client setup: spawn of the bridge task fails (runtime shutdown), the reconnect/policy wiring fails, or the transport setup between leader and follower fails immediately.

Common situations: Calling client setup outside a live tokio runtime; system resource exhaustion (can't spawn threads/tasks); the peer process for the bridge dying instantly so the spawn handshake fails; misconfigured leader address causing immediate connect error.

Related errors

• initialize through bridge
• Task panicked: {}
• authenticate through bridge
• set on the use_leader path
• PTY write channel closed

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/11da6c15b2e7ab0c. Report an issue: GitHub.