Fix benchmark version count scans

[olearycrew]

Problem

GET /api/benchmark_versions was contributing disproportionate D1 read load: each request loaded visible benchmark versions, then issued one COUNT(*) query per version. With roughly 10 visible versions and no submissions.benchmark_version index, this could scan the submissions table repeatedly for every API request.

Root Cause

The N+1 query path lived in src/routes/benchmarkVersions.ts, where each benchmark version independently executed:

SELECT COUNT(*) as count FROM submissions WHERE benchmark_version = ?

Because submissions.benchmark_version was not indexed, each count could require a full submissions scan.

Solution

• Replaced per-version submission counts with one grouped aggregate over the visible version IDs.
• Added idx_submissions_benchmark_version to schema.sql and a D1 migration so the grouped aggregate and the latest-version count can use an index.
• Added a minimal GitHub Actions workflow because this worktree did not contain an existing CI workflow, ensuring npm ci and npm test run on future PRs.
• Synchronized package-lock.json so npm ci can install the already-declared test dependencies reproducibly.

Test Coverage

• Added a before/after parity test for GET /api/benchmark_versions using a production-equivalent fixture with 10 visible versions, hidden versions, zero-submission versions, semver/prerelease ordering, legacy labels, and 1,000 representative submissions.
• The parity test builds the legacy N+1 snapshot and asserts the optimized endpoint returns identical version payloads.
• Added a regression/metric assertion that caps the endpoint at two D1 statements total and one submissions count query, failing if one count per version returns.

Run locally with:

npm ci && npm test

Validated locally: npm ci && npm test passed with 45 tests.

Metrics Impact

For /api/benchmark_versions, visible-version count reads drop from 1 + N D1 statements per request to 2 D1 statements per request. With 10 visible versions, that is 11 statements to 2 statements, an expected ~82% reduction in D1 statement count for this endpoint plus indexed access instead of repeated submissions table scans.

Risks & Mitigations

• Risk: hidden versions or zero-count versions could disappear from the response. Mitigated by parity coverage for hidden and zero-submission fixtures.
• Risk: semver and legacy ordering could change. Mitigated by parity coverage across release, prerelease, invalid semver, and null semver rows.
• Risk: migration index creation can take time on a large D1 table. Mitigated with CREATE INDEX IF NOT EXISTS; rollout should still be monitored during migration application.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	pinchbench-api	19f94a9	Commit Preview URL Branch Preview URL	Jun 08 2026, 06:35 PM

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

This PR is in excellent shape. The two optimizations are well-executed:

1. Leaderboard correlated-subquery → window function (leaderboard.ts): The new buildLeaderboardQuery uses a ROW_NUMBER() OVER (PARTITION BY model …) CTE (ranked_best) to pick best_submission_id in a single ranked pass, eliminating the per-model correlated scalar subquery. Provider-filter semantics are intentionally preserved (best submission ID ignores provider filter, matching legacy behavior) and the test confirms this explicitly.

2. Submissions COUNT join elision (submissions.ts): The JOIN tokens t in the pagination COUNT query is now only emitted when verified=true actually needs t.claimed_at. Both the JOIN and the WHERE condition are guarded by the same verified flag, so there's no risk of referencing an absent table alias.

Files Reviewed (7 files)

• src/routes/benchmarkVersions.ts — previous review; no issues
• src/routes/leaderboard.ts — window-function refactor; no issues
• src/routes/leaderboard.test.ts — parity + correlated-subquery regression tests; solid coverage
• src/routes/submissions.ts — conditional token JOIN for COUNT; no issues
• src/routes/submissions.test.ts — parity + join-elision tests; good coverage
• schema.sql — previous review; no issues
• migrations/20260608_add_submissions_benchmark_version_index.sql — previous review; no issues
• .github/workflows/test.yml — step labels, node 22→24, push branch filter; no issues
• package-lock.json — generated; skipped

---

_{Reviewed by claude-4.6-sonnet-20260217 · 110,023 tokens}