xai-org/grok-build · error · ManagedConfigError

timed out after {:?}

Error message

timed out after {:?}

What it means

During managed text config validation, the configured validator command is spawned as a child process and its output is read with a timeout (`validator.timeout`). If the process produces no completing result before the deadline, validation fails with 'timed out after {timeout:?}', including any teardown error as supplementary detail. This guards the config pipeline against validators that hang.

Source

Thrown at crates/codegen/xai-grok-config/src/managed_text/validator.rs:96

    let started = Instant::now();
    loop {
        match ops.try_wait(&mut child) {
            Ok(Some(status)) if status.success() => return Ok(()),
            Ok(Some(status)) => {
                return Err(validation_error(
                    path,
                    format!("{} exited with {status}", validator.program.display()),
                    None,
                ));
            }
            Ok(None) if started.elapsed() < validator.timeout => {
                std::thread::sleep(Duration::from_millis(10));
            }
            Ok(None) => {
                let teardown = ops.teardown(&mut child, group.as_ref()).err();
                return Err(validation_error(
                    path,
                    format!("timed out after {:?}", validator.timeout),
                    teardown,
                ));
            }
            Err(source) => {
                let teardown = ops.teardown(&mut child, group.as_ref()).err();
                return Err(validation_error(path, source.to_string(), teardown));
            }
        }
    }
}

fn validation_error(path: &Path, primary: String, teardown: Option<String>) -> ManagedConfigError {
    let reason = match teardown {
        Some(teardown) => format!("{primary}; process teardown also failed: {teardown}"),
        None => primary,
    };
    ManagedConfigError::Validation {
        path: path.to_path_buf(),

View on GitHub (pinned to bc7f02eddd)

Solutions

  1. Increase `validator.timeout` in the managed-text config to cover the validator's worst-case runtime.
  2. Run the validator command manually on the same file to find why it hangs (stdin prompt, network wait, lock contention).
  3. Ensure the validator runs non-interactively (pass flags like --no-input / CI mode) and does not require a TTY.
  4. Pre-warm caches or vendor the validator binary so first-run cost does not exceed the deadline.

Example fix

# before
[[managed_text.validator]]
cmd = "typst"
timeout = "2s"
# after: give the validator headroom
[[managed_text.validator]]
cmd = "typst"
timeout = "30s"
Defensive patterns

Strategy: validation

Validate before calling

# pre-check: run the validator manually with a stopwatch before trusting the configured timeout
time $VALIDATOR_CMD /path/to/sample.conf

Try / catch

match validate_temp(path) {
  Err(ManagedConfigError::Validation(msg)) if msg.contains("timed out after") => {
    eprintln!("validator exceeded timeout: {msg}; raising validator.timeout");
  }
  Err(e) => return Err(e),
  Ok(v) => apply(v),
}

Prevention

When it happens

Trigger: The validator binary for a config file (e.g. an linter/formatter invoked on a temp copy) blocks longer than `validator.timeout` — a hung process waiting on stdin, a network-bound linter, a deadlock, or a timeout set far below the tool's real startup time.

Common situations: First-run tool download/compile inside the validator exceeding the timeout on cold caches; validator prompting for input in a non-TTY; slow network mounts or antivirus scanning; timeouts tuned for fast machines applied to CI runners.

Understand the failure class

Related errors

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