ui: replace the never-useful latency heatmap with a command-latency panel - #245
Merged
Conversation
srikanth-bitdynamics
force-pushed
the
fix/metrics-heatmap-064
branch
from
July 11, 2026 05:43
060d279 to
561fb61
Compare
srikanth-bitdynamics
changed the title
srikanth-bitdynamics
force-pushed
the
fix/metrics-heatmap-064
branch
from
July 11, 2026 07:15
95c69de to
d31f36e
Compare
The Submit-to-commit heatmap buckets sequencing latency by the histogram's `le` boundaries. Stock Splice 0.6.4 exports that histogram with only the +Inf bucket, so every observation collapsed into the top (>2s) row — the panel read ">2s" for latency that is actually ~100ms, contradicting the average shown right above it. Same root cause as the hidden p50/p95/p99 strip. When no finite `le` bucket is present, show a short note explaining the density can't be resolved and pointing at the average, instead of the misleading grid. The grid returns automatically on Splice versions whose histograms carry finite buckets. The bucket-vs-note decision is extracted to a pure heatmapCellsOrNote() helper with a regression test.
Bringing up a Splice 0.6.9 LocalNet showed the note read "Not available on Splice 0.6.4" on a 0.6.9 instance — the +Inf-only histogram is the whole 0.6.x line, not 0.6.4 specifically (verified: 0.6.9 also exports a single-bucket histogram, histogram_quantile is NaN there too). Reword to "this Splice version" so it's correct on any affected instance.
The submit-to-commit heatmap never populates on any supported Splice version — 0.6.x exports the sequencing histogram with only the +Inf bucket (verified on 0.6.4 and 0.6.9), so a latency-density map has nothing to plot. Rather than leave a permanent "not available" note in that slot, put a metric there that is both important and actually live. Per Canton's observability guidance the documented golden signals (storage load, in-flight/dirty requests, node health) sit at zero on an idle LocalNet. The command-submission duration — Canton's documented command-latency signal — is a real average (sum/count) that populates and moves, and it restores a working latency view at the participant / ledger API layer (distinct from the sequencer-side "Sequencing latency" panel). Removes the heatmap machinery (loadHeatmap, heatmapCellsOrNote, the note), adds Q.cmdLatency through the existing per-node loader, and swaps the regression test to guard the query stays a real average, not a percentile.
srikanth-bitdynamics
force-pushed
the
fix/metrics-heatmap-064
branch
from
July 11, 2026 08:29
d31f36e to
e8e25bc
Compare
srikanth-bitdynamics
changed the base branch from
main
to
webui-type-scale-hybrid
July 11, 2026 08:29
zheli
pushed a commit
that referenced
this pull request
Jul 11, 2026
…le (#250) * style(webui): hybrid type scale — bump prose, keep data dense Refines the flat 16px bump into a role-aware scale for a console that is scanned and operated, not read top to bottom. Only prose grows; operational data stays at its tight baseline so dense tables, metric values, and mono IDs keep their density. - Page titles -> 22, descriptions -> 15 - Prose section / card / dialog headings -> 15-16 - Empty-state and dialog body copy -> 14-15 - Untouched: table cells & headers, MonoId, metric values/labels/units, chart labels, status badges, nav/topbar, chips, ports, kbd, buttons. 65 fontSize increases across 20 files. No data sizes changed; tsc + build green. * style(webui): centralize the type scale as rem tokens (fold in #249) Adopts #249's accessibility approach — a named rem `fs` scale in tokens.ts so the console honors the browser/OS font-size — on top of #250's role-aware sizing. The root is now 100% and every inline fontSize references an fs.* token, so operational data stays dense, prose reads larger, and the whole UI scales with the reader's font-size preference. - New `fs` rem scale: micro/label/meta/data/body/lead/strong/title/stat. - ~440 inline fontSize px literals -> fs tokens (value-preserving, so the approved hybrid sizing is unchanged); MonoId and chart labels included. - index.css root -> 100%, its font-sizes -> rem. Combines what #248 (flat px) and #249 (flat rem) each had half of. tsc + 218 frontend tests green. * ui: replace the never-useful latency heatmap with a command-latency panel (#245) * fix(ui): don't render a misleading latency heatmap on Splice 0.6.4 The Submit-to-commit heatmap buckets sequencing latency by the histogram's `le` boundaries. Stock Splice 0.6.4 exports that histogram with only the +Inf bucket, so every observation collapsed into the top (>2s) row — the panel read ">2s" for latency that is actually ~100ms, contradicting the average shown right above it. Same root cause as the hidden p50/p95/p99 strip. When no finite `le` bucket is present, show a short note explaining the density can't be resolved and pointing at the average, instead of the misleading grid. The grid returns automatically on Splice versions whose histograms carry finite buckets. The bucket-vs-note decision is extracted to a pure heatmapCellsOrNote() helper with a regression test. * fix(ui): make the heatmap "not available" note version-neutral Bringing up a Splice 0.6.9 LocalNet showed the note read "Not available on Splice 0.6.4" on a 0.6.9 instance — the +Inf-only histogram is the whole 0.6.x line, not 0.6.4 specifically (verified: 0.6.9 also exports a single-bucket histogram, histogram_quantile is NaN there too). Reword to "this Splice version" so it's correct on any affected instance. * ui: replace the latency heatmap with a command-latency panel The submit-to-commit heatmap never populates on any supported Splice version — 0.6.x exports the sequencing histogram with only the +Inf bucket (verified on 0.6.4 and 0.6.9), so a latency-density map has nothing to plot. Rather than leave a permanent "not available" note in that slot, put a metric there that is both important and actually live. Per Canton's observability guidance the documented golden signals (storage load, in-flight/dirty requests, node health) sit at zero on an idle LocalNet. The command-submission duration — Canton's documented command-latency signal — is a real average (sum/count) that populates and moves, and it restores a working latency view at the participant / ledger API layer (distinct from the sequencer-side "Sequencing latency" panel). Removes the heatmap machinery (loadHeatmap, heatmapCellsOrNote, the note), adds Q.cmdLatency through the existing per-node loader, and swaps the regression test to guard the query stays a real average, not a percentile.
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
2 participants
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.
Stacked on #250 — base is that branch, so this diff shows only the command-latency change. Merge #250 first; GitHub retargets this to
mainautomatically.Problem
The Metrics screen's Submit-to-commit heatmap (latency density) never populates on any supported Splice version: 0.6.x exports the sequencing-duration histogram with only the
+Infbucket (verified live on 0.6.4 and 0.6.9), so there's no bucket distribution to plot. The earlier version of this PR just hid it behind a "not available" note — but that's permanent dead space.Fix
Replace the panel with a metric that is both important and actually live: Command latency (
daml_participant_api_commands_submissions_duration_seconds, avg ms per node).Why this metric (researched against docs.canton.network + the live instance):
Removes the heatmap machinery (
loadHeatmap,heatmapCellsOrNote, the note constant, theHeatmap/Cellimports) and wiresQ.cmdLatencythrough the existing per-node loader. The regression test now guards that the query is a real average, not a percentile.Verification
tscclean, full frontend suite green (219 tests). Verified live on a 0.6.9 LocalNet: the panel renders per-node command latency (app-provider 30 ms, app-user 33 ms, sv 16 ms); the heatmap is gone.