Series limit isn't applied in SQL for metric charts: every series is fetched, then capped in the browser #3502

What happened?

With seriesLimit: 2 and a group-by over 5 hosts, on main (2bfc630):

renderSeriesLimitCte skips metric sources ("Skip CTE/metric sources (no real table to re-scan)"):

• https://github.com/hyperdxio/hyperdx/blob/2bfc6307dc0c9b84d0f3ff68e1beeaf0b4fcc877/packages/common-utils/src/core/renderChartConfig.ts#L1552-L1567

The app relies on that CTE, and otherwise caps the series client-side:

• https://github.com/hyperdxio/hyperdx/blob/2bfc6307dc0c9b84d0f3ff68e1beeaf0b4fcc877/packages/app/src/ChartUtils.tsx#L206-L253

So a top-N metric chart on a high-cardinality attribute reads, aggregates and transfers every series, then the browser draws N of them. On our deployment:

• a top-20 chart over a histogram with ~280 groups read 76 GB;
• a top-10 chart over a sum with ~2,700 groups hit our 8 GiB per-query memory limit.

Expected: metric charts return the top N series from SQL, as log and trace charts do. The ranking could run on the per-series values after the metric CTEs, before the final pivot.

Related: #3204 (how the top N is picked across chunks).

Steps to reproduce

Reproduces on play.hyperdx.io? Didn't try.

An integration test in the style of renderChartConfig.int.test.ts, on main:

1. Insert a gauge, a cumulative sum and a cumulative histogram repro.many for hosts h1–h5 (ResourceAttributes['host']).
2. renderChartConfig with groupBy: "ResourceAttributes['host']", seriesLimit: 2, granularity: '5 minute', and one select of each metric type in turn.
3. Each query returns all 5 hosts. The same config on a log source with groupBy: 'ServiceName' returns 2.

How are you running HyperDX?

Helm (ClickStack chart 2.1.0) with the hyperdx:2-nightly image (2.42.0 plus the Node bump from #3456), our own ClickHouse 26.2.5.45. Reproduced on main 2bfc630.

Where does it show up?

Dashboard time charts on metric sources with "Top N series"; we saw the cost through the MCP tools and in system.query_log.

Debug info

N/A.

Logs

None.

Written with help from an AI assistant (Claude Code). The behaviour comes from our own deployment and an integration test on main.