infiniflow/ragflow · error · TimeoutError

Execution timed out after {exec_timeout} seconds

Error message

Execution timed out after {exec_timeout} seconds

What it means

Raised when running the user's script via `sandbox.commands.run(...)` throws `sdk.TimeoutException`: the command did not finish within `exec_timeout`, which is min(requested_timeout, self.timeout). Before running, the provider extends the sandbox lifetime to max(sandbox_timeout, exec_timeout+30) so the VM outlives the command. Note this TimeoutError fires after execution started — contrast with error 265 which fires at creation.

Source

Thrown at agent/sandbox/providers/ucloud_agent_sandbox.py:208

        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)
        sdk = _get_ucloud_sandbox_module()

        start_time = time.time()
        try:
            sandbox.set_timeout(max(self.sandbox_timeout, exec_timeout + 30), request_timeout=self.timeout)
            result = sandbox.commands.run(
                f"{executable} {shlex.quote(script_path)}",
                cwd=remote_work_dir,
                timeout=exec_timeout,
                request_timeout=max(self.timeout, exec_timeout),
            )
        except sdk.CommandExitException as exc:
            result = exc
        except sdk.TimeoutException as exc:
            raise TimeoutError(f"Execution timed out after {exec_timeout} seconds") from exc
        except Exception as exc:
            raise RuntimeError(f"UCloud Agent Sandbox execution failed: {exc}") from exc
        execution_time = time.time() - start_time

        stdout = result.stdout or ""
        stderr = result.stderr or ""
        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,
            exit_code=exit_code,
            execution_time=execution_time,
            metadata={
                "instance_id": instance_id,
                "sandbox_id": sandbox.sandbox_id,

View on GitHub (pinned to 554fb1133a)

Solutions

  1. Fix the user code to finish within the limit (add internal deadlines, bounded loops).
  2. Raise the timeout — and remember the provider-level `timeout` config caps it, so raise both.
  3. Catch TimeoutError in the agent loop and report a user-readable 'code took too long' result instead of crashing the session.
  4. For legitimately long jobs, run them outside the sandbox or chunk the work.

Example fix

# before
result = provider.execute(inst, "train_model()", timeout=120)  # provider timeout=30 -> dies at 30s

# after
# raise the provider-level cap too: config timeout=300
result = provider.execute(inst, "train_model()", timeout=120)
Defensive patterns

Strategy: retry

Validate before calling

# cannot precheck user-code runtime; enforce a script-level budget instead
wrapper = "import time\ntime_left = %d\n" % exec_timeout + user_code
# or at minimum ensure per-call timeout does not exceed the provider cap
exec_timeout = min(int(timeout or provider.timeout), provider.timeout)

Type guard

def is_execution_timeout(exc: TimeoutError) -> bool:
    return "timed out after" in str(exc)

Try / catch

try:
    result = provider.execute(instance_id, code, timeout=60)
except TimeoutError as e:
    result = make_result(stderr=f"execution {e}: reduce workload or raise provider 'timeout' config")
    # only rerun with a larger timeout if the provider-level cap allows it

Prevention

When it happens

Trigger: User code with an infinite loop, blocking network read, or long computation executed with exec_timeout shorter than the runtime; per-call timeout requested below the work's real duration.

Common situations: LLM-generated code with `while True:` or unbounded polling; scripts sleeping longer than the timeout; raising per-call timeout but forgetting the provider-level `timeout` cap (exec_timeout is min()ed against it, so a per-call 120 with provider timeout 30 still runs only 30s).

Understand the failure class

Related errors


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