infiniflow/ragflow · warning · TimeoutError

Execution timed out after {exec_timeout} seconds

Error message

Execution timed out after {exec_timeout} seconds

What it means

TimeoutError raised when sandbox.exec() throws errors.CommandTimeoutError or errors.PrimitiveTimeoutError: the user script did not finish within exec_timeout, which is min(requested_timeout, self.timeout). The provider logs a warning with the instance id and effective timeout before raising.

Source

Thrown at agent/sandbox/providers/tenki.py:217

        instance = self._instances[instance_id]
        sandbox = instance["sandbox"]
        remote_work_dir: str = instance["remote_work_dir"]
        errors = self._tenki_errors()

        args_json = json.dumps(arguments or {}, ensure_ascii=False)
        script_path, argv = self._prepare_script(sandbox, remote_work_dir, normalized_lang, code, args_json)

        requested_timeout = self.timeout if timeout is None else int(timeout)
        if requested_timeout <= 0:
            raise RuntimeError(f"Execution timeout must be greater than 0 seconds, got {requested_timeout}.")
        exec_timeout = min(requested_timeout, self.timeout)

        start_time = time.time()
        try:
            result = sandbox.exec(*argv, cwd=remote_work_dir, timeout=exec_timeout)
        except (errors.CommandTimeoutError, errors.PrimitiveTimeoutError) as exc:
            logger.warning("Tenki execution timed out (instance=%s, timeout=%ss)", instance_id, exec_timeout)
            raise TimeoutError(f"Execution timed out after {exec_timeout} seconds") from exc
        except (errors.SessionTerminatedError, errors.SessionNotFoundError) as exc:
            # The sandbox was reclaimed (e.g. max_lifetime) or lost mid-run;
            # surface it as RuntimeError per the base contract, not an SDK type.
            raise RuntimeError(f"Tenki sandbox is no longer available: {exc}") from exc
        except Exception as exc:
            raise RuntimeError(f"Tenki execution failed: {exc}") from exc
        execution_time = time.time() - start_time

        stdout = result.stdout_text
        stderr = result.stderr_text
        exit_code = int(result.exit_code)

        self._validate_output_size(stdout, stderr)
        stdout, structured_result = extract_structured_result(stdout)

        return ExecutionResult(
            stdout=stdout,
            stderr=stderr,

View on GitHub (pinned to 554fb1133a)

Solutions

1. Raise timeout in the initialize() config (per-call values are clamped to it) and pass an explicit per-call timeout.
2. Fix or bound the generated script: add iteration limits, avoid sleep loops, stream results in chunks.
3. Treat TimeoutError separately from RuntimeError in callers — the sandbox survives a command timeout, so retrying with a shorter/cheaper script on the same instance is safe.

Example fix

# before
provider.initialize({"api_key": key, "timeout": 30})
provider.execute_code(inst, slow_code, timeout=120)  # silently clamped to 30

# after
provider.initialize({"api_key": key, "timeout": 120})
provider.execute_code(inst, slow_code, timeout=120)

effective = provider.timeout if timeout is None else min(int(timeout), provider.timeout)
if effective < estimated_runtime_seconds:
    logger.warning("script may exceed tenki timeout of %ss", effective)

try:
    result = provider.execute_code(instance_id, code, timeout=t)
except TimeoutError:
    # sandbox survives; retry cheaper/bounded script on the same instance
    result = provider.execute_code(instance_id, bounded_code, timeout=t)

When it happens

Trigger: Running code that loops forever, sleeps, or is simply slower than the timeout — e.g. default 30s config with a 60s computation; or requesting a larger timeout than the provider config, which gets clamped down to self.timeout.

Common situations: LLM-generated code with infinite loops or long sleeps; forgetting that the per-call timeout can never exceed the provider-level timeout set in initialize(); heavy data processing inside the sandbox.

Understand the failure class

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

Related errors

• Execution timed out after {exec_timeout} seconds
• Execution timed out after {timeout} seconds
• Execution timed out after {exec_timeout} seconds
• Execution timed out after {exec_timeout} seconds
• Execution timeout must be greater than 0 seconds, got {reque

AI-assisted analysis of infiniflow/ragflow@554fb1133a (2026-08-15). Data as JSON: /api/errors/60af663073b4df3f. Report an issue: GitHub.