fix(accounts): take subnet_count from a GROUP BY subquery, not COUNT(DISTINCT)

[JSONbored]

Summary

• fix(accounts): the account summary card reads all zeros while its own detail routes read real rows #9254 (PR fix(accounts): serve the account summary card from the lakehouse #9257) merged, deployed, and the card still serves zeros. This is my bug, found by probing production after the merge.

Verified 33 minutes post-merge, three sequential probes:

/api/v1/accounts/{ss58}  ->  event_count 0, event_kinds 0, recent_events 0

Not deploy lag — /chain/weights/setters (#9251) began serving data over the same window.

Cause

The aggregate read used count(DISTINCT netuid). R2 SQL rejects an ungrouped count(DISTINCT) at this scale:

40015: scan budget exceeded: scanning too much data for count(DISTINCT) without GROUP BY

Identical to the failure the #9251 correction found. I wrote this reader before that landed and reasoned the CTE's LIMIT 5000 made the DISTINCT cheap. It does not — the planner still evaluates the DISTINCT against the underlying scan, so being inside a capped CTE saves nothing.

The rejected query returned null, the loader declined exactly as designed, and the handler fell through to buildAccountSummary(ss58, {}). The decline path was correct; the query should never have been sent.

Fix

subnet_count now comes from its own GROUP BY subquery — the shape #9251 settled on:

WITH scan AS (…) SELECT count(*) AS sc FROM (SELECT netuid FROM scan GROUP BY netuid)

count(*) stays ungrouped: a plain row count carries no DISTINCT, so neither the budget rejection nor the wrong-question problem applies to it.

Guard

A test asserting no read in this loader uses COUNT(DISTINCT) at all, mirroring the one added alongside the #9251 fix. Confirmed it bites by reintroducing the original query (1 failed | 8 passed).

Worth recording

This class of failure is invisible to the fake-engine tests. The query typechecks, every local assertion passes, and it reads correctly — only a production probe after deploy shows the engine refusing it. Both instances of this bug (mine here, and #9251's) were found that way, not by CI.

Registry Safety

• Links a tracked, currently-open issue (Closes #9281) — required.
• No secrets, PATs, wallet data, private dashboards, private URLs, or validator-local state.
• Generated artifacts were produced by repo scripts, not hand-edited.
• R2-only/high-churn detail artifacts are not committed.
• No schema change; validate:contract-drift green.

Validation

• npm run typecheck · npm run lint · npm run format:check
• npm run validate · npm run validate:contract-drift · npm run scan:public-safety
• npm run worker:test
• npx vitest run — 15,087 tests passing
• Patch coverage: diff lines ∩ v8 uncovered set = ∅ (48 changed lines)

[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	Updated (UTC)
✅ Deployment successful! View logs	metagraphed-data-api	e927140	Aug 03 2026, 12:48 PM

[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	Updated (UTC)
✅ Deployment successful! View logs	metagraphed-registry-sync-api	e927140	Aug 03 2026, 12:48 PM

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[JSONbored]

Superseded by #9282, which landed the same fix on main — the distinct subnet count is now its own GROUP BY subquery over the capped scan window (src/account-feeds-cold-tier.ts), so the ungrouped count(DISTINCT netuid) that R2 SQL rejects with 40015: scan budget exceeded is gone.

Verified in production for the address this was reported against:

event_count   : 5000     (was 0)
subnet_count  : 2        (was 0)
registrations : 1        (netuid 46, uid 232 — matches /subnets exactly)

Three sessions independently found this same bug and wrote the same remedy today; #9287 was closed for the same reason. Nothing here is lost — the branch now conflicts against a main that already contains its change.

One piece of fallout worth noting: #9282 and #9285 were each green against the main they branched from, but together the test stubs in #9285 kept matching on count(DISTINCT netuid) — a marker #9282 had removed — which turned main red until #9295 fixed the stubs to match each read's actual clause.