t8y2/dbx · error · RuntimeError

{process.candidate.name} paged query returned {rows} rows, e

Error message

{process.candidate.name} paged query returned {rows} rows, expected {workload['max_rows']}

What it means

After draining all pages of a 'paged' workload, execute_workload asserts the accumulated row count equals workload['max_rows'] and raises RuntimeError naming the candidate when they differ. This catches truncation or over-fetch in paging behavior so benchmark results are only trusted when the query returned exactly the expected rows.

Source

Thrown at agents/drivers/hive-go/bench/agent_compare.py:527

                    "sessionId": session_id,
                    "pageSize": workload["page_size"],
                    **({"agentSessionId": agent_session_id} if agent_session_id else {}),
                },
            )
            rows += len(page.get("rows", []))
            session_id = page.get("session_id")
            has_more = page.get("has_more", False)
    finally:
        if session_id:
            process.call(
                "close_query_session",
                {
                    "sessionId": session_id,
                    **({"agentSessionId": agent_session_id} if agent_session_id else {}),
                },
            )
    if rows != workload["max_rows"]:
        raise RuntimeError(
            f"{process.candidate.name} paged query returned {rows} rows, "
            f"expected {workload['max_rows']}"
        )
    return rows


def sample_result(count: int, elapsed: float, samples: list[float]) -> dict:
    summary = summarize_latencies(samples)
    summary.update(
        {
            "count": count,
            "elapsed_ms": elapsed * 1000,
            "ops_per_sec": count / elapsed,
        }
    )
    return summary

View on GitHub (pinned to c0390bff16)

Solutions

Compare the returned count against max_rows and inspect the agent's paging logic for missed or duplicated pages
Verify the table actually contains max_rows rows before the benchmark (check setup/load step)
Rerun with a single worker to rule out concurrency interference
Fix the candidate driver's pagination (e.g. last-page detection, offset math)

Defensive patterns

Strategy: validation

Validate before calling

def verify_row_count(conn, table: str, expected: int) -> None:
    actual = conn.execute(f"SELECT COUNT(*) FROM {table}").fetchone()[0]
    if actual != expected:
        raise SystemExit(f"{table} has {actual} rows, expected {expected}")
verify_row_count(conn, "bench_table", workload["max_rows"])  # before benchmarking

Try / catch

try:
    rows = execute_workload(process, paged_workload, ...)
except RuntimeError as e:
    if "paged query returned" in str(e):
        print(f"paging mismatch, rerun single-threaded to isolate: {e}")
        rows = execute_workload(single_process, paged_workload, ...)
    else:
        raise

Prevention

Verify table row counts match the scenario after data setup
Test each candidate's pagination with a small known dataset first
Avoid concurrent writers mutating the table during benchmarks
Add per-page row accounting in the agent to spot lost/duplicated pages

When it happens

Trigger: A paging implementation drops pages (rows < max_rows), duplicates or over-fetches rows (rows > max_rows), or the underlying data changed between setup and the run; also occurs when the agent's session/page state is inconsistent across page fetches.

Common situations: Candidate driver with a paging bug (off-by-one in offsets, missed last page); concurrent workload mutating the table mid-benchmark; total rows fewer than max_rows because the setup data load failed partially; session reuse across workers causing skipped pages.

Related errors

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