xai-org/grok-build · error · acp::Error

-32603

-32603

Error message

{action} timed out after {}s. It may still finish in the background; retrying right away can run into the same delay.

What it means

An ACP -32603 InternalError raised by acp_send_bounded when a session RPC wrapped in tokio::time::timeout(session_rpc_timeout()) does not complete in time. The message names the action and the configured timeout, and warns the operation may still complete in the background, so an immediate retry may hit the same delay.

Source

Thrown at crates/codegen/xai-grok-pager/src/app/effects/helpers.rs:42

pub(super) fn session_rpc_timeout() -> std::time::Duration {
    SESSION_RPC_FLOOR.max(xai_grok_workspace::envrc::loader_budget() + SESSION_RPC_SLACK)
}
/// `acp_send` bounded by [`session_rpc_timeout`]; on expiry, an error naming `action` instead of an eternal spinner.
pub(super) async fn acp_send_bounded<R, T>(
    request: T,
    tx: &tokio::sync::mpsc::UnboundedSender<R>,
    action: &str,
) -> Result<T::Response, acp::Error>
where
    T: xai_acp_lib::AcpRequest,
    R: From<xai_acp_lib::AcpArgs<T>> + std::fmt::Debug,
{
    let timeout = session_rpc_timeout();
    match tokio::time::timeout(timeout, acp_send(request, tx)).await {
        Ok(result) => result,
        Err(_elapsed) => {
            Err(
                acp::Error::new(
                    acp::ErrorCode::InternalError.into(),
                    format!(
                "{action} timed out after {}s. It may still finish in the background; \
                 retrying right away can run into the same delay.",
                timeout.as_secs()
            ),
                ),
            )
        }
    }
}
/// Typed progress message for session restore.
/// Keeps the progress channel from accepting arbitrary `TaskResult` variants.
pub(crate) struct RestoreProgressMsg {
    pub agent_id: AgentId,
    pub message: String,
}
pub(super) fn log_prompt_result(

View on GitHub (pinned to bc7f02eddd)

Solutions

Increase session_rpc_timeout() to accommodate the slow action
Retry after waiting, since the action may still finish in the background (avoid immediate retry per the message)
Investigate why the session handler is slow or stuck (logs around the action)
Check backend health/latency for the underlying model or RPC

Defensive patterns

Strategy: retry

Validate before calling

// sanity-check the timeout budget before issuing the call
let t = session_rpc_timeout();
assert!(t > Duration::from_secs(5), "session_rpc_timeout too small");

Try / catch

match result {
  Err(e) if e.code == -32603 && e.message.contains("timed out") => {
    tokio::time::sleep(backoff).await; // wait before retry, action may still complete
    retry_with_longer_timeout()
  }
  r => r,
}

Prevention

Set session_rpc_timeout generously for long actions
Use exponential backoff instead of immediate retries
Monitor session handler latency and backend health

When it happens

Trigger: Any ACP request routed through acp_send_bounded whose future does not resolve within session_rpc_timeout() — slow model/streaming session, blocked session task, or a very low timeout configuration.

Common situations: Long-running prompts against a slow backend; overloaded server leaving the session unresponsive; session_rpc_timeout set too low for the workload; deadlocked session handler.

Understand the failure class

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

Related errors

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