mirror of
https://github.com/XRPLF/rippled.git
synced 2026-08-21 14:20:56 +00:00
All five TraceQL panels on this dashboard returned nothing, and did so without any visible error: they filtered on span.close_time_correct=~"$close_time_correct", but close_time_correct is a boolean attribute (RCLConsensus.cpp:601 passes a raw bool), and Tempo restricts the regex operator to string operands, so the spanset resolved to false. With the variable defaulting to All the clause rendered as =~".*", so the panels were empty out of the box and looked exactly like a node with no consensus activity. Note this is the opposite of PromQL, where an absent or empty label does match ".*" — which is why the 17 Prometheus panels on this same board were unaffected and the dashboard appeared healthy. Dropped the clause from all six queries, matching phases 9 and 10 where it is already gone. The $close_time_correct variable now filters the Prometheus "Close Time Agreement" panel instead, which already grouped by that label but never filtered on it, so the control stays useful rather than becoming dead UI. Two defects were masked behind the empty panels and are fixed too: - "Close Time: Raw Proposals" and "Close Time: Effective / Quantized" carried unit dateTimeFromNow over close_time_self/close_time, which are NetClock seconds (Ripple epoch), while Grafana's dateTime formatters expect a millisecond Unix epoch — every point would have rendered as roughly 1970. They now plot as plain numbers with the axis labelled "NetClock Seconds (Ripple Epoch)", and the descriptions give the 946684800 offset for converting to Unix time. - "Close Time Vote Bins & Resolution" matched its unit and axis overrides byName against "Vote Bins" and "Resolution", which are not field names; TraceQL select() yields close_time_vote_bins and close_resolution_ms, so neither override applied. Switched to byRegexp so the match holds whichever scope prefix Grafana emits. No panel was added or removed: the (type, title) multiset is unchanged at 22. resolution_direction keeps its regex filter, which is correct there — it is set from a std::string whose values are exactly the variable's increased/decreased/unchanged.