fix(adhoc): support Map-typed columns in ad-hoc filters

[adamyeats]

Summary

Fixes #1434 — ad-hoc filters on Map(...) columns previously failed in two ways, both entirely in the plugin (despite the issue's waiting-on-clickhouse label, no upstream change is required):

1. Filter values dropdown showed [object Object]. fetchTagValuesFromSchema() issued SELECT DISTINCT <col> against a Map column, returning whole Map values that the frontend stringified via String(value).
2. Filters silently produced invalid SQL for non-OTel Map columns. escapeKey() used a hard-coded allowlist of three OTel names (ResourceAttributes, ScopeAttributes, LogAttributes) and treated every other dotted key as a table prefix, so user-defined Map columns and OTel variants like SpanAttributes didn't work.

What this changes

1. Map-aware tag-keys expansion (src/data/CHDatasource.ts)

getTagKeys() now inspects the type column from system.columns, collects Map-typed columns per-table, and — when the adhoc context points at a specific db.table — fans out parallel fetchUniqueMapKeys() probes and expands each Map column into one tag key per discovered map key. Falls back to the flat entry when no table context is available (avoids N-table fan-out on database-wide adhoc variables).

Detection handles Map(...), Nullable(Map(...)), and LowCardinality(Map(...)).

2. Map-aware tag-values fetch (src/data/CHDatasource.ts)

fetchTagValuesFromSchema() recognises dotted keys whose head refers to a Map-typed column (from the cache populated in step 1) and rewrites the SELECT to SELECT DISTINCT col['key'] FROM … instead of SELECT DISTINCT col FROM …. Fixes the [object Object] dropdown.

3. Schema-driven escapeKey (src/data/adHocFilter.ts)

Replaces the three-name allowlist with a schema-driven set published by the datasource via AdHocFilter.setMapColumns(). The OTel names remain as fallback defaults so behavior does not regress for users who hand-construct AdHocFilter or whose tables use the canonical names. Now correctly handles:

• table.MapCol.key1.key2 → MapCol['key1.key2'] (table-prefixed)
• MapCol.key → MapCol['key'] (no prefix, e.g. hideTableNameInAdhocFilters=true)
• table.plain_col → plain_col (unchanged, non-Map dotted path)

Tests

• Unit tests for all three paths in src/data/adHocFilter.test.ts and src/data/CHDatasource.test.ts.
• New e2e regression guard tests/e2e/mapFilter.spec.ts runs the exact SQL shapes our adhoc code paths produce (mapKeys discovery, bracket-access values, full additional_table_filters apply) against a real ClickHouse fixture added to tests/e2e/fixtures/seed.sql (e2e_test.map_events with a Map(String, String) column).

Scope notes

• Probes are gated to specific db.table adhoc contexts. Database-wide or schema-wide adhoc variables still show the flat Map-column entry to avoid a per-table fan-out on every dashboard render. A follow-up can relax this if needed.
• OTel fallback preserved. setMapColumns() is additive — DEFAULT_MAP_COLUMNS (ResourceAttributes, ScopeAttributes, LogAttributes) is always merged in. Tests that construct AdHocFilter directly without a datasource still pass.
• Aligned with #1461 — both this and the JSON-path discovery bug share a "sample map-like keys from a large table" pattern. This PR reuses the existing fetchUniqueMapKeys() implementation; if #1461's sampling strategy changes, this will inherit it for free.

Related

• Touches the same escapeKey() / dotted-column-path area as #798 (dots in column names). Not fixed here but adjacent.
• #1063 (adhoc filter no-ops in Logs view) may also be resolved by the Bug 2 fix if the underlying cause is SQL rejection — worth a repro after this lands.

Closes #1434