Homepage leaderboard has been empty in production since late July

What's wrong

The leaderboard on https://www.localscore.ai/ renders its tab chrome (Tiny/Small/Medium, GPU/CPU+GPU/CPU) but zero rows. It's been that way for about three weeks.

The page's own data payload is empty:

GET https://www.localscore.ai/_next/data/build-TfctsWXpff2fKS/index.json
→ {"pageProps":{"results":[]},"__N_SSG":true}

Everything else is fine

This is worth stressing, because it narrows things a lot:

• /latest shows results through today
• /api/search returns live models and accelerators (newest accelerator rows dated 2026-08-16)
• /accelerator/4016 renders normally
• /model/3 — Llama 3.2 1B Q4_K-M, one of the three OFFICIAL_MODELS — renders a full 826-accelerator leaderboard

So the database, accelerator_model_performance_scores, and the official model variants are all healthy. / is the only getStaticProps page in the app; every other data page is getServerSideProps. That's why this one page is dark and nothing else is.

It's not a stale cache and not a bad deploy

• ISR is genuinely cycling: polling the data route shows age climbing to ~60, flipping to x-vercel-cache: STALE, then resetting to ~19 as a fresh entry is written. It regenerates every 60s and regenerates to empty.
• Wayback has the homepage with results = 3 populated model groups (20/13/12 accelerators) on 2026-07-22, and results: [] on 2026-08-05. Both carry the same buildId build-TfctsWXpff2fKS that production is serving right now.

Same deployment, same code, same lockfile, working one day and empty the next. Nothing shipped — it broke underneath a running deployment.

Where it breaks

getPerformanceScores builds its output by mapping over modelInfo, so if it received even one variant id you'd get 3 groups with empty inner arrays. A length-0 outer array can only mean getModelVariants returned zero rows.

That's the only query in the codebase using SQLite row-value tuple IN (src/db/queries.ts):

where ("models"."name", "model_variants"."quantization") in ((?,?), (?,?), (?,?))

The rows it's looking for are definitely there — /api/search returns Llama 3.2 1B Instruct / Q4_K - Medium, Meta Llama 3.1 8B Instruct / Q4_K - Medium and Qwen2.5 14B Instruct / Q4_K - Medium, matching OFFICIAL_MODELS character for character. I reproduced the exact generated SQL against libsql/SQLite 3.45 locally, both small and at ~3,900-row scale with the same unique indexes, and it returns all three rows.

Given the unchanged buildId, that points at the production database engine rather than the repo. A Turso engine migration where row-value IN (VALUES…) isn't handled the same way would fit both the behaviour and the timing, though I can't verify that from outside the account.

Why it failed silently

Worth fixing separately from the query itself. Once getModelVariants returns [], nothing downstream complains: drizzle compiles inArray(col, []) to where false rather than throwing, so getTopAcceleratorsByModelVariants returns [], getPerformanceScores maps over an empty modelInfo, and getStaticProps returns a valid page with no data. No exception, no error page, no stale-cache signal — which is why a broken headline feature stayed up for three weeks without tripping anything.

Having getStaticProps throw (or skip revalidate) when modelVariants.length === 0 would turn a future recurrence into something visible.

Proposed fix

#40 rewrites the tuple IN as OR-of-AND pairs — portable, no dependency on row-value support, same index usage per EXPLAIN QUERY PLAN. Verified behaviour-preserving by running the full getStaticProps chain against the committed db.sqlite before and after (identical 3 groups, 4/2/7 accelerators); tsc --noEmit clean and npm run build produces a populated prerender.

getAccelerators has the same tuple shape and the same latent bug, so it's fixed there too.

One caveat I'd flag: the engine hypothesis is inference, not something I could confirm from outside. If running that tuple query directly against the production Turso DB does return the three rows, then the cause is something else and the PR is only a hardening change — happy to keep digging if that's what you find.

Start in src/db/queries.ts with getModelVariants and getAccelerators, then trace their results through getPerformanceScores and the homepage getStaticProps path. Run the tuple query and the full getStaticProps chain against the committed db.sqlite, followed by tsc --noEmit and npm run build. Done means the homepage prerender contains the expected three model groups and the related queries no longer depend on the failing behavior.