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

For "paged" workloads execute_workload counts the rows returned across all execute_query_page pages and asserts the total equals the workload's declared max_rows; a mismatch raises RuntimeError naming the candidate, actual and expected counts. This guards benchmark correctness — a candidate that silently truncates or duplicates rows would otherwise skew comparisons.

Source

Thrown at agents/drivers/argo-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

Update the workload's max_rows in the config to match the actual table row count (or regenerate the test table to the expected size)
Fix the agent's pagination loop so it fetches until the cursor is exhausted
Make the workload SQL deterministic (stable ORDER BY, fixed dataset) and re-run
Log each page's row count inside the pagination loop to locate which page short-changed the total

Example fix

// before
{"kind": "paged", "sql": "SELECT * FROM bench.events", "max_rows": 100000}
// after
# re-sync test data, or:
{"kind": "paged", "sql": "SELECT * FROM bench.events", "max_rows": 98250}  # actual count

Defensive patterns

Strategy: validation

Validate before calling

actual = table_row_count(sql)
if actual != workload["max_rows"]:
    raise ValueError(f"workload max_rows={workload['max_rows']} but table has {actual} rows")

Try / catch

try:
    rows = execute_workload(process, workload, agent_session_id)
except RuntimeError as e:
    if "paged query returned" in str(e):
        print(f"row-count mismatch: {e}; regenerate test data or update max_rows")
    else:
        raise

Prevention

Regenerate the test table and max_rows together; never mutate shared bench data mid-run
Use deterministic queries (fixed WHERE, stable ORDER BY)
Log per-page row counts to find where pagination drifts
Re-verify counts after agent upgrades that change paging behavior

When it happens

Trigger: Agent returns fewer or more rows than workload["max_rows"] during paged execution: early end-of-stream, page aggregation bug, query returning a different row count than declared, or a mid-pagination error swallowed by the driver loop.

Common situations: Test table was modified (rows added/deleted) after max_rows was fixed in the workload config; agent's pager stops before exhausting the cursor; SQL with non-deterministic ORDER BY plus LIMIT yields different totals; concurrent benchmark runs mutating shared data.

Related errors

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