t8y2/dbx · error · TimeoutError

timed out during {method}

Error message

timed out during {method}

What it means

AgentProcess.call waits on a one-slot queue for the JSON-RPC response with BENCH_RPC_TIMEOUT (default 180s); when queue.get raises queue.Empty the call converts it into a TimeoutError naming the method. This means the request was written to the agent's stdin but no response line arrived in time.

Source

Thrown at agents/drivers/argo-go/bench/agent_compare.py:99

        with self.request_lock:
            self.request_id += 1
            request_id = self.request_id
            response_queue: queue.Queue = queue.Queue(maxsize=1)
            self.pending[request_id] = response_queue
        request = {
            "jsonrpc": "2.0",
            "id": request_id,
            "method": method,
            "params": params or {},
        }
        try:
            assert self.process.stdin is not None
            with self.write_lock:
                self.process.stdin.write(json.dumps(request, separators=(",", ":")) + "\n")
                self.process.stdin.flush()
            response = response_queue.get(timeout=env_float("BENCH_RPC_TIMEOUT", 180.0))
        except queue.Empty as error:
            raise TimeoutError(self._failure(f"timed out during {method}")) from error
        finally:
            with self.request_lock:
                self.pending.pop(request_id, None)
        if isinstance(response, Exception):
            raise response
        if response.get("error") is not None:
            raise RuntimeError(
                f"{self.candidate.name} {method}: "
                f"{json.dumps(response['error'], ensure_ascii=False)}"
            )
        return response.get("result")

    def rss_kib(self) -> int:
        if self.candidate.rss_command:
            output = subprocess.check_output(
                self.candidate.rss_command,
                shell=True,
                text=True,

View on GitHub (pinned to c0390bff16)

Solutions

  1. Increase the BENCH_RPC_TIMEOUT environment variable (e.g. 600) for long-running workloads
  2. Reduce workload size (max_rows / page_size / number of queries) so each call finishes within the timeout
  3. Check agent logs/stderr for a hang or deadlock and fix the agent's concurrency handling
  4. Verify the agent echoes the request `id` back so the response is routed to the pending queue
  5. Add retry logic around call() in the harness for transient slow queries

Example fix

// before
response = response_queue.get(timeout=env_float("BENCH_RPC_TIMEOUT", 180.0))
// after
# shell: export BENCH_RPC_TIMEOUT=600  # or in harness
response = response_queue.get(timeout=env_float("BENCH_RPC_TIMEOUT", 600.0))
Defensive patterns

Strategy: try-catch

Validate before calling

timeout = float(os.getenv("BENCH_RPC_TIMEOUT", "180"))
assert timeout > expected_query_seconds, "increase BENCH_RPC_TIMEOUT for this workload"

Try / catch

try:
    result = process.call(method, params)
except TimeoutError as e:
    print(f"{method} exceeded BENCH_RPC_TIMEOUT: {e}")
    process.close()
    process = AgentProcess(process.candidate)  # dead/hung agent must be recycled

Prevention

When it happens

Trigger: Calling any method whose handler blocks longer than BENCH_RPC_TIMEOUT: huge result sets in execute_query, agent deadlock, agent busy on a previous synchronous request, hung JDBC/backend connection, or response id mismatch so the pending queue never receives the reply.

Common situations: Benchmarking pages queries over a slow remote Hive/TDengine where one query exceeds 180s; agent deadlocks on concurrent requests; wrong BENCH_RPC_TIMEOUT for a large max_rows workload; agent silently dropped the response due to a protocol bug.

Understand the failure class

Related errors


AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05). Data as JSON: /api/errors/802062c585907cf7. Report an issue: GitHub.