Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Filter key and value limits are unordered and not configurable — fields and values silently disappear

Aperta
  • Qualcosa non va?
#3,097 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
clickhouse, react, typescript
Ambito
backend, databases, frontend, observability

Direzione di ricerca

Inizia da packages/common-utils/src/core/metadata.ts, seguendo getAllFields, getMapKeys, getAllKeyValues, getKeyValues e il pattern di troncamento di getMetricNames. Poi esamina packages/app/src/hooks/useMetadata.tsx, TeamQueryConfigSection.tsx e DBSearchPageFilters/hooks.ts per il flusso di configurazione e il rendering dei filtri. Il lavoro è completo quando i limiti configurabili raggiungono discovery e i valori, i risultati troncati sono deterministici e vengono mostrati nella UI.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement external

Field discovery and value autocomplete both truncate to a fixed number of results with no ORDER BY. On a high-cardinality source the survivors are an arbitrary subset, the UI gives no sign anything was dropped, and the one team setting that looks like it controls this doesn't reach either path.

We hit this on a source with ~6,150 distinct LogAttributes keys. Roughly 5,150 of them are invisible in the filter sidebar and there is no way to raise the ceiling.

Keys: capped at 1000, and Filter Keys Fetch Limit doesn't apply

getAllFields calls getMapKeys without maxKeys, so DEFAULT_MAX_KEYS = 1000 always wins:

The team setting exists (TeamQueryConfigSection.tsx:320, "Filter Keys Fetch Limit") but is only read in useMultipleGetKeyValues, where it slices the already-truncated key array: useMetadata.tsx:372-373, applied at useMetadata.tsx:411. Raising it above 1000 changes nothing; lowering it below 1000 only trims what discovery already returned. Confirmed on the wire — discovery queries carry LIMIT 1000 regardless of the setting.

Keys: the text-index path has no ORDER BY

getMapKeys returns from the first non-empty path of four. On ClickHouse 26.4 with a text index on mapKeys(LogAttributes), the text-index path wins and the KV rollup is never consulted:

Compare the rollup path, which does order by frequency: metadata.ts:846-853 — ORDER BY sum(count) DESC. Adding a text index therefore makes field discovery worse: you trade a frequency-ranked list for an arbitrary one.

Values: capped at a hardcoded 20, also unordered

The SQL is groupUniqArray(limit)(…) throughout, with no ordering: 2570-2571, 2605, 1428, 1257, 1334.

"Load More" raises one key to 10,000 (hooks.ts:36), but it's a manual per-key click. The initial 20 that decides whether the value you're looking for is on screen at all has no setting behind it.

This is already documented in the codebase

metadata.ts:2652-2669 explains why getMetricNames avoids getKeyValues:

groupUniqArray(limit)(MetricName) "keeps an arbitrary subset once a table has more than limit distinct names — the survivors follow hash order, not name order, and shift as the data and part layout change. On a high-cardinality source (a full Prometheus scrape) that silently hid metrics such as up, with no way to search for what had been dropped."

And useMetadata.tsx:526 tells callers to "Prefer this over useGetKeyValues({ keys: ['MetricName'] }), which samples an arbitrary subset via groupUniqArray".

The fix applied there is exactly what's missing everywhere else: a deterministic ORDER BY, LIMIT limit + 1, and a truncated flag so the caller knows the list was cut. A truncated field already exists in the shared type at metadata.ts:77.

What we'd like

A cap is reasonable. Being unable to raise it, and not being told it applied, is not.

  1. Pass maxKeys from filterKeysFetchLimit through getAllFields into getMapKeys, so the existing setting actually controls key discovery.
  2. Add a team setting for max values per key, replacing the hardcoded 20 in useMetadata.tsx:412 and INITIAL_LOAD_LIMIT.
  3. Add ORDER BY to the truncating queries — frequency for keys (as the rollup path already does), something deterministic for values — so the subset is at least stable and useful.
  4. Surface truncation in the UI, reusing the limit + 1 / truncated pattern from getMetricNames.
Environment
  • HyperDX 2.37.0, ClickHouse Cloud 26.4
  • otel_logs with text indexes on mapKeys(LogAttributes), mapKeys(ResourceAttributes), mapKeys(ScopeAttributes)
  • ~6,150 distinct LogAttributes keys per 15-minute window
Lingua principale
TypeScript
Stelle
10k
Fork
494
Merge medio
2g 14h
PR unite (30g)
142

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hyperdxio/hyperdx

Tutte le issue di hyperdxio/hyperdx

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.