#9276 added a serving-Worker overlay that fills nominator_count from the frozen lakehouse mirror of chain.validator_nominator_counts. It was the bridge for the period when D1 had no data. That period is over, and the overlay should come down.
What it actually does now (correcting an earlier characterisation)
It is not simply dead code. validatorHotkeysNeedingCount collects only hotkeys whose count is null, so after #9334's confirmed-zero change the overlay fires in exactly one situation: the counts query threw while the neurons query succeeded. A full D1 outage takes the neurons read with it, so there is no payload to enrich and the overlay never runs.
In that narrow partial-failure case it serves ~557 counts stamped 2026-08-02, and the lakehouse copy is permanently frozen — nothing refreshes it, so those values age indefinitely. That is the failure src/validator-nominator-counts-cold-tier.ts's own header warns about: a degraded count is worse than no count, because a card cannot tell its reader which one it got. Null is the honest answer there.
Scope
12 call sites across three serving surfaces, plus the module and its suite:
workers/request-handlers/entities.ts (2)src/graphql.ts (3)src/mcp-server.ts (3)src/validator-nominator-counts-cold-tier.ts (146 lines)tests/validator-nominator-counts-cold-tier.test.ts (389 lines)
Each call site is a multi-line expression wrapper (await enrichValidatorNominatorCounts(env, <payload expr>)) with different nesting, so removal is careful unwrapping rather than a find-replace — which is why it wants its own PR with the full suite behind it rather than being tacked onto unrelated work.
Not urgent
Serving is complete and correct today: nominator_count is non-null on 1,028/1,028 validators, and the overlay no-ops on every healthy request.
Part of #9146
#9276 added a serving-Worker overlay that fills
nominator_countfrom the frozen lakehouse mirror ofchain.validator_nominator_counts. It was the bridge for the period when D1 had no data. That period is over, and the overlay should come down.What it actually does now (correcting an earlier characterisation)
It is not simply dead code.
validatorHotkeysNeedingCountcollects only hotkeys whose count is null, so after #9334's confirmed-zero change the overlay fires in exactly one situation: the counts query threw while the neurons query succeeded. A full D1 outage takes theneuronsread with it, so there is no payload to enrich and the overlay never runs.In that narrow partial-failure case it serves ~557 counts stamped
2026-08-02, and the lakehouse copy is permanently frozen — nothing refreshes it, so those values age indefinitely. That is the failuresrc/validator-nominator-counts-cold-tier.ts's own header warns about: a degraded count is worse than no count, because a card cannot tell its reader which one it got. Null is the honest answer there.Scope
12 call sites across three serving surfaces, plus the module and its suite:
workers/request-handlers/entities.ts(2)src/graphql.ts(3)src/mcp-server.ts(3)src/validator-nominator-counts-cold-tier.ts(146 lines)tests/validator-nominator-counts-cold-tier.test.ts(389 lines)Each call site is a multi-line expression wrapper (
await enrichValidatorNominatorCounts(env, <payload expr>)) with different nesting, so removal is careful unwrapping rather than a find-replace — which is why it wants its own PR with the full suite behind it rather than being tacked onto unrelated work.Not urgent
Serving is complete and correct today:
nominator_countis non-null on 1,028/1,028 validators, and the overlay no-ops on every healthy request.Part of #9146