Repository navigation
Conversation
Adds /ethereum/consensus/fast-confirmation. Every epoch a fast confirmation node has scored since it started reporting is drawn as one cell, one row per UTC day, coloured by the slowest block in the epoch. Clicking a cell or a scar opens that epoch's 32 blocks per client. The page also lists the worst runs of late confirmations, the distribution of time to fast confirmation against time to finality, and a per-client summary. API types regenerated for fct_block_fast_confirmation_by_node, fct_block_fast_confirmation_by_client_hourly and fct_block_fast_confirmation_by_client_daily.
![redpandabot[bot]](https://avatars.githubusercontent.com/in/3749543?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary
Adds a Fast Confirmation page under /ethereum/consensus/fast-confirmation with an epoch lattice, per-client summary, scar list, epoch detail and a distribution chart, plus generated API types for the three fct_block_fast_confirmation_* tables. The page code follows existing repo conventions and the utility logic and tests are consistent. Only two minor display-accuracy issues found, nothing blocking.
Issues
- 🟢
src/pages/ethereum/consensus/fast-confirmation/fast-confirmation.utils.ts:260— Epoch straddling an hour boundary can be shown as 'not reporting' — see the thread on that line - 🟢
src/pages/ethereum/consensus/fast-confirmation/components/ConfirmationDistribution/ConfirmationDistribution.tsx:85— Histogram is per node-observation but labelled 'Share of blocks' — The distribution feeds every canonical (block, node) row from fct_block_fast_confirmation_by_node without deduplicating per block (unlike summarizeSlots, which takes the min across nodes), so the y-axis 'Share of blocks (%)' actually measures share of observations and weights blocks by how many nodes reported them.
Reviewed @ b7fc6463
"All non-trivial abstractions, to some degree, are leaky." — Joel Spolsky
| startTime, | ||
| day: (dayStart - firstDay) / 86_400, | ||
| column: Math.min(columns - 1, Math.floor((startTime - dayStart) / EPOCH_SECONDS)), | ||
| tier: covered.has(hour) ? tierForMs(lateEntry ? lateEntry.worstMs : null) : 'none', |
There was a problem hiding this comment.
🟢 Epoch straddling an hour boundary can be shown as 'not reporting'
buildField paints an epoch only if the hour containing its start is covered (covered.has(hour)), but ~1 in 9 epochs spans two hours; if the node only scored that epoch's blocks in the second hour, the cell renders as 'Node not reporting' despite the epoch being scored.
1 participant
Adds a Fast Confirmation page at
/ethereum/consensus/fast-confirmation. Every epoch a fast confirmation node has scored since it started reporting is drawn as one cell, one row per UTC day, coloured by the slowest block in that epoch, and clicking a cell or an entry in the scar list opens the epoch's 32 blocks per client. The page also has a per-client summary and the distribution of time to fast confirmation against time to finality. API types are added for the threefct_block_fast_confirmation_*tables from ethpandaops/xatu-cbt#304.