Telemetry resource facet counts still read primaryEntityId — OTLP clusters and hosts show count 0

[simlarsen]

Follow-up to #3216 / #3245.

#3245 makes selecting a Kubernetes Cluster / Host / Docker host / Podman host facet actually filter OTLP-ingested telemetry, by resolving the resource to its entity key and matching primaryEntityId IN (...) OR hasAny(entityKeys, [...]).

The displayed count next to each facet value was deliberately left alone: LogAggregationService.buildFacetStatement (and the trace counterpart) still computes resource-facet counts as

SELECT toString(primaryEntityId) AS val, count() AS cnt
FROM <table>
WHERE ... AND primaryEntityType = '<ResourceType>'
GROUP BY val

which only counts agent-ingested rows whose primary entity IS the resource. For pure-OTLP telemetry (rows primary-keyed on their Service), the sidebar lists the cluster (from the Postgres inventory via ResourceFacetResolver) with count 0 — while selecting it returns all its rows. This is repro step 2 of #3216, still visible after #3245.

Sketch

The facet values for these facets come from Postgres, so the resolver already knows each resource's id and (after #3245's ResourceEntityFilter) its entity key. Counts could be computed per resource with one scan and no double counting:

SELECT
  countIf(primaryEntityId = {id_1} OR has(entityKeys, {key_1})) AS cnt_1,
  countIf(primaryEntityId = {id_2} OR has(entityKeys, {key_2})) AS cnt_2,
  ...
FROM <table>
WHERE projectId = ... AND time BETWEEN ... -- plus the other active facet scopes

(countIf with OR rather than two grouped queries, because agent-ingested rows can match both branches.)

Needs doing for the logs and traces facet-count endpoints, and should reuse ResourceEntityFilter's id → identifier → key resolution so read-side keys keep byte-matching ingest.

🤖 Generated with Claude Code