Bound high-cardinality chart rendering work

[ktsaou]

What changed

• make chart render requests idempotent with monotonic payload revisions and independent per-UI freshness cursors
• preserve retries for blocked or failed renders, plus existing resize and settings behavior
• skip the unused built-in Dygraphs legend plugin when Netdata supplies its own legend
• prevent nested Dygraphs option updates from triggering recursive redraws
• bound grouped-context matching, dimension-sort accessors, and result-statistics aggregation
• refresh React chart values only after a successful new payload instead of every generic render request
• add generated Storybook coverage for 100, 1,000, 5,000, and 10,000 dimensions

Root cause

The live play loop emitted render requests every second for every loaded active chart. Those requests reached the chart library even when no data, size, or setting had changed, so high-cardinality charts repeatedly rebuilt their complete data and options.

Additional work was magnified inside those necessary renders:

• Dygraphs ran its built-in legend plugin despite Netdata using a separate React legend
• a units-conversion update could start a nested redraw during an outer redraw
• context matching scanned dimensions repeatedly
• sort comparators repeatedly resolved the same names and values
• result statistics repeatedly looked up columns by string label for every point
• React value selectors treated a render request as proof that data had changed

Behavior and compatibility

This does not change queries, payload contracts, dashboard definitions, filtering, chart results, or visible live-update semantics.

New payloads still render. Actual resize and render-affecting setting changes still update immediately. A render blocked by highlighting, panning, or processing remains stale and retries instead of being acknowledged.

Validation

• 143 Jest suites passed
• 1,370 tests passed and 2 skipped
• CommonJS build compiled 462 files
• ES-module build compiled 462 files
• static Storybook build passed
• focused ESLint, formatting, and whitespace checks passed

Runtime evidence

On the same high-cardinality dashboard:

• after the freshness boundary, a settled foreground sample used 0.003 seconds of JavaScript over 15.7 seconds, with stable heap and no requests
• the nested Dygraphs update fell from about 3.40 seconds to 0.012 seconds
• total JavaScript during the measured focus refresh fell from 12.58 seconds to 9.02 seconds before the later bounded-processing corrections