infiniflow/ragflow · error · TimeoutError

Execution timed out after {exec_timeout} seconds

Error message

Execution timed out after {exec_timeout} seconds

What it means

Raised by SelfManagedProvider.execute_code() when the requests.post call to {endpoint}/run raises requests.Timeout — the remote sandbox service did not answer within exec_timeout seconds (the per-call timeout argument, or the provider's configured timeout as fallback). The provider converts it to a built-in TimeoutError, deliberately distinguishing 'service never answered' from non-zero exits inside the sandbox.

Source

Thrown at agent/sandbox/providers/self_managed.py:178

                stderr=result.get("stderr", ""),
                exit_code=result.get("exit_code", 0),
                execution_time=execution_time,
                metadata={
                    "status": result.get("status"),
                    "time_used_ms": result.get("time_used_ms"),
                    "memory_used_kb": result.get("memory_used_kb"),
                    "detail": result.get("detail"),
                    "instance_id": instance_id,
                    "artifacts": result.get("artifacts", []),
                    "result_present": structured_result.get("present", False),
                    "result_value": structured_result.get("value"),
                    "result_type": structured_result.get("type"),
                },
            )

        except requests.Timeout:
            execution_time = time.time() - start_time
            raise TimeoutError(f"Execution timed out after {exec_timeout} seconds")

        except requests.RequestException as e:
            raise RuntimeError(f"HTTP request failed: {str(e)}")

    def destroy_instance(self, instance_id: str) -> bool:
        """
        Destroy a sandbox instance.

        Note: For self-managed provider, instances are returned to the
        internal pool automatically by executor_manager after execution.
        This is a no-op for tracking purposes.

        Args:
            instance_id: ID of the instance to destroy

        Returns:
            True (always succeeds for self-managed)
        """

View on GitHub (pinned to 554fb1133a)

Solutions

  1. Pass a larger timeout to execute_code(instance_id, code, language, timeout=N) sized to the workload.
  2. Raise the provider-level 'timeout' in the initialize() config so the fallback covers unparameterized calls.
  3. Split long jobs into resumable chunks with per-chunk progress written by the executed code.
  4. If timeouts persist for fast code, check sandbox-service health/network — a hung service times out even on trivial payloads.

Example fix

# before
result = provider.execute_code(instance_id, code, "python")  # default timeout

# after
result = provider.execute_code(instance_id, code, "python", timeout=300)
Defensive patterns

Strategy: retry

Validate before calling

timeout_needed = estimate_runtime(code)
assert provider.timeout >= timeout_needed or pass_explicit_timeout  # plan ahead
result = provider.execute_code(instance_id, code, "python", timeout=max(30, timeout_needed))

Try / catch

import time
for attempt in range(2):
    try:
        result = provider.execute_code(instance_id, code, "python", timeout=300)
        break
    except TimeoutError:
        if attempt == 1:
            raise
        time.sleep(2)

Prevention

When it happens

Trigger: Executed code running longer than the timeout passed to execute_code() while the sandbox service holds the connection; a low provider timeout configured at initialize() with a larger per-call timeout argument NOT passed (per-call timeout wins: exec_timeout = timeout or self.timeout); sandbox service hung or network black-holing the connection.

Common situations: Long computations (training loops, big sorts) exceeding a 30s default; forgetting that the timeout parameter of execute_code() must be raised for heavy work; a stuck executor container; network middleboxes dropping idle HTTP connections so the response never arrives.

Understand the failure class

Related errors


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