[msaroufim]

Leaderboard requests were exhausting Gunicorn's 30-second timeout and returning 500/503 responses. Scope and materialize run metadata for the requested leaderboard, compute submission counts once across GPUs, and fetch validation summaries only for winning runs. Preserve tied runs, distinct submission counts, secret-test eligibility, and hacked-submission filters. Cache null results for ended leaderboards so empty competitions stop triggering repeated SQL.

Production mitigation already applied: two concurrent partial indexes for secret-test eligibility, VACUUM ANALYZE of runs/submissions, and lower run-table vacuum thresholds. The repeatable SQL is in docs/operations/leaderboard-query-indexes.sql. QR v2 recovered from a 31.6-second HTTP 503 to HTTP 200 in 4.0 seconds after database maintenance, before this application deployment.

Validation:

• 45 API, hacked-filter, and database tests passed, including new tie/count and empty-cache regression tests; Ruff passed.
• Read-only comparisons in the same production snapshots returned identical rankings/metadata for QR v2, Cholesky, leaderboard 598, and leaderboard 770. With JIT disabled equally for both comparison queries, old/new timings were 25.4s/1.9s, 11.2s/0.7s, 31.2s/6.7s, and 0.24s/0.007s. These are incident-time samples, not controlled benchmarks.
• Full tests/: 54 passed, 9 legacy page-rendering failures (before the final tie test). The same legacy tests also fail on unchanged main; API coverage passes.
• Modal production runner is deployed; no recent bot error logs. The observed failure was in the board's SQL path.

The query still scales with submissions within one leaderboard; this change bounds it to that leaderboard and avoids scanning other competitions. Database maintenance ran without blocking normal writes.