| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| @hyperdx_common-utils@0.31.0 source code.tar.gz | 2026-10-13 | 17.4 MB | |
| @hyperdx_common-utils@0.31.0 source code.zip | 2026-10-13 | 18.5 MB | |
| README.md | 2026-10-13 | 4.3 kB | |
| Totals: 3 Items | 35.9 MB | 0 | |
Minor Changes
- 6873416d: feat: Add a series mode to builder heatmaps
- ff5befa8: Support "Minimum auto granularity" on PromQL sources. It floors the step of charts on auto granularity, as it does for metric sources, and
$__rate_intervalnow uses it as the source's scrape interval (still 15s when unset) instead of always assuming 15s. A granularity picked on a tile is never changed. - d8b1cdfa: feat: Attribute PromQL queries to the dashboard, tile or search that issued them, through both the
prometheusQuery/prometheusQueryRangetable functions and ClickHouse's Prometheus HTTP API - ab703243: feat: attribute ClickHouse queries to the dashboard, tile, search or alert that issued them
A row in system.query_log previously couldn't be attributed to the part of
HyperDX that produced it. Now every query HyperDX runs has a small JSON
log_comment, plus a query_id starting with hdx-.
Attribute load after the fact:
sql
SELECT
JSONExtractString(log_comment, 'surface') AS surface,
JSONExtractString(log_comment, 'dashboard') AS dashboard,
JSONExtractString(log_comment, 'tile') AS tile,
count(),
sum(read_rows)
FROM system.query_log
WHERE type = 'QueryFinish' AND log_comment != '' AND query_id like 'hdx-%'
GROUP BY ALL
ORDER BY sum(read_rows) DESC
Or spot a query while it is still running, in system.processes, where the
query_id names the surface with no JSON parsing needed.
The payload records which part of the product asked (a dashboard, a search, an alert, an MCP tool, the chart explorer, session replay, field lookups, and so on), the dashboard and tile or saved search id, the source id, and on the server the trace id of the request. Field lookups and autocomplete are labelled too, so they can be told apart from a user's chart queries.
The exception is queries that skip settings processing: the system.settings,
server version and Cloud-detection probes, and the onboarding connection check.
They get a query_id but an empty log_comment.
- 68082b67: feat: add stacked line (stacked area) time-series display type
Patch Changes
- 07c93656: fix: cast FixedString columns before implicit hasToken search
A bare search term against a FixedString column such as OTel TraceId compiled to hasToken(lower(TraceId), ...), which ClickHouse rejects. Those haystacks are now CAST to String first.
- 0b855534: fix: fall back to the Map key scan when the text index read fails
getMapKeys returned an empty list whenever its mergeTreeTextIndex query
failed, so the rollup and bounded mapKeys scan paths never ran. ClickHouse
refuses mergeTreeTextIndex with ACCESS_DENIED on any table with a row
policy, which left search autocomplete with no Map keys on those tables. A
failed text index read now falls through to the next strategy. After a row
policy denial it skips the key rollup table, which the policy doesn't cover,
and reads keys only from the policy-filtered source table.
- 0846f3b2: Include the requested Map-key limit in metadata cache keys so MCP discovery and AI field discovery cannot reuse each other's differently limited results.
- e61461be: feat: auto-detect a PromQL source during onboarding
When PromQL is enabled (NEXT_PUBLIC_ENABLE_PROMQL=true), onboarding source auto-detection now also creates a PromQL source for a ClickHouse TimeSeries engine table. It prefers prometheus.metrics (the table the ClickHouse Prometheus docs suggest), then a table named metrics_ts, and otherwise picks the only TimeSeries table on the connection. A service with only a TimeSeries table is no longer sent to manual source setup.
- 1be9de8f: feat: Add a promql variable format that escapes based on single/multi-select
- 0d2425d5: feat: Allow configuring dashboard filters as single-select
- 1ce8b88e: fix: rank Map keys by frequency when a text index serves key discovery
The two mergeTreeTextIndex paths in getMapKeys grouped keys and applied
LIMIT maxKeys with no ORDER BY, so on a column with more keys than the
limit the filter sidebar showed an arbitrary subset. They now order by
sum(cardinality) DESC, key, which keeps the most frequent keys, as the key
rollup path already does with sum(count) DESC.