Repository navigation
every unranked row on the site publishes 0 in its headline column - #3343
Merged
Merged
Conversation
The ledger renders unranked rows with `value={0}` hard-coded, the same prop
the unresponsive rows get. For an unresponsive row that is right: there is
no value. For an unranked row it throws away a measured number that the
loader took deliberate care to preserve.
In production right now: Nova reads 0 on /benchmarks/perp-active-markets
while its own row carries 493, and CoW and Bebop read 0 on
evm-quote-output against 3.17 and 163.75.
The data half of this was already fixed once, and load.ts:395 records what
it cost: "zeroing them published 0.00 bps for a venue giving up a hundred".
The loader now blanks ms only when the spec asks with
`unranked_hides_value`. The component kept zeroing regardless, so the
correct value arrived at the browser and was discarded on the way to the
cell.
Unranked is a statement about comparability, not about whether the number
exists. A row that genuinely has nothing to show asks for that explicitly,
and for it the loader has already zeroed ms before the component sees it,
so that case is unchanged.
Found by reading the rendered page instead of the API: the API said 61 for
the new RouteMesh row and the cell said 0 ms, with p90, p99 and mean from
the same row all correct.
Verified locally: Nova 0 -> 493, RouteMesh 0 -> 64 ms, and a ranked row
left alone as the control.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Oct 28, 2026
Flotapponnier
added a commit
that referenced
this pull request
Oct 29, 2026
#3347) * every unranked row on the site publishes 0 in its headline column (#3343) The ledger renders unranked rows with `value={0}` hard-coded, the same prop the unresponsive rows get. For an unresponsive row that is right: there is no value. For an unranked row it throws away a measured number that the loader took deliberate care to preserve. In production right now: Nova reads 0 on /benchmarks/perp-active-markets while its own row carries 493, and CoW and Bebop read 0 on evm-quote-output against 3.17 and 163.75. The data half of this was already fixed once, and load.ts:395 records what it cost: "zeroing them published 0.00 bps for a venue giving up a hundred". The loader now blanks ms only when the spec asks with `unranked_hides_value`. The component kept zeroing regardless, so the correct value arrived at the browser and was discarded on the way to the cell. Unranked is a statement about comparability, not about whether the number exists. A row that genuinely has nothing to show asks for that explicitly, and for it the loader has already zeroed ms before the component sees it, so that case is unchanged. Found by reading the rendered page instead of the API: the API said 61 for the new RouteMesh row and the cell said 0 ms, with p90, p99 and mean from the same row all correct. Verified locally: Nova 0 -> 493, RouteMesh 0 -> 64 ms, and a ranked row left alone as the control. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit a02560c) * the ranked chart ranked the rows the ledger refuses to rank (#3345) The ledger puts an unranked row in a labelled block below the field and never gives it a number. The ranked bar chart, which sits above the ledger and is the first thing anyone reads, ranked them anyway. So RouteMesh came out "#5" against the very providers it forwards to, which is exactly the comparison the unranked flag exists to refuse, while the table three inches below showed it as unranked. The two surfaces contradicted each other on the same screen, and the louder one was wrong. distribution-chart.tsx and public-endpoints-section.tsx already filter on unrankedLabel. This surface was the one that did not. Excluded from the ranking, not from the page: the ledger keeps the row and its number, because not being ranked is a statement about comparability, not a reason to hide a measurement. Same distinction as the fix two commits ago, which stopped the ledger printing those numbers as zero. Verified locally: the chart now ranks QuickNode, GetBlock, Chainstack, Dwellir and BlockMachine, RouteMesh is absent from it, and the ledger row still reads 64 ms with its region breakdown. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 719ed5a) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A live bug on published benches, found while checking the new RouteMesh row.
What happens
ledger-table.tsxrenders unranked rows withvalue={0}hard-coded, the same prop the unresponsive rows get.For an unresponsive row that is right: there is no value. For an unranked row it throws away a measured number that the loader took deliberate care to preserve.
In production today:
The data half was already fixed once
load.ts:395records what it cost:The loader now blanks
msonly when the spec asks withunranked_hides_value. The component kept zeroing regardless, so the correct value reached the browser and was discarded on the way to the cell.Unranked is a statement about comparability, not about whether the number exists. A row that genuinely has nothing to show asks for that explicitly, and for it the loader has already zeroed
msbefore the component sees it, so that case is unchanged by this PR.How it surfaced
The new RouteMesh row read
0 mson the page while the variant API read60.97, withp90,p99andmeanfrom the same row all correct. Three wrong explanations died first: a stale cache (p90 moved from 125 to 128 between reads while p50 stayed 0), a sparse-histogram warm-up (the per-region recording rules were already returning 27.5, 123.0 and 40.7), and an active panel defaulting to zero (there are none on these pages).Two of my own reads were wrong before that: one truncated the row at 90 characters so the number landed in the cut, the other assumed a column order. Mapping cells to their own header row settled it.
Verified locally
Gates:
tsc --noEmitclean,bun test src/745 pass 0 fail.