Where-clause: support OR groups (and make dependency drilldowns collision-safe)

[Makisuo]

Problem

The where-clause parser (parseWhereClause in packages/domain/src/where-clause.ts) silently drops (a OR b) groups. It emits a parse warning, but the rest of the clause still runs. A filter that needs an OR is therefore quietly wider than intended.

This was found through the service Dependencies tab (#1190), where the drilldowns relied on OR:

• The HTTP drill (server.address = X OR http.host = X) never filtered on its target.

• A messaging or RPC edge can merge two sets of spans when a destination (or rpc.service) is literally named after its system, e.g. a Kafka topic called kafka. In that case the service-map rollup (service_external_edges_hourly_mv) puts two groups into one edge:

  • spans whose destination is kafka
  • spans with no destination, which fall back to the system name

  Matching both groups needs messaging.system = "kafka" AND (messaging.destination.name = "kafka" OR messaging.destination.name !exists). Today the drill reaches only the fallback group. The limitation is documented in apps/web/src/components/services/dependency-drill.ts and pinned by a test in dependency-drill.test.ts.

Options

1. Support OR groups in the parser and query builder. This is the general fix and helps saved dashboards, alerts and MCP query_data filters too. It needs grammar work in where-clause.ts, an attribute filter shape that can express a disjunction, and the matching SQL in buildAttrFilterCondition (packages/query-engine/src/traces-shared.ts).
2. Carry a fallback flag on the edge. Have the edge rollup record whether TargetName came from the system fallback, so the drill can pick the right single filter. This needs a materialized-view change and doesn't help other OR use cases.
3. Add a pseudo-key whose alias chain matches the rollup's TargetName expression. For example, messaging.target coalescing messaging.destination.name, messaging.destination and messaging.system, so one = clause equals the edge exactly. It's cheap, but it's a Maple-only key users could see in autocomplete.

Option 1 seems like the right long-term answer. When it lands, the pinned test in dependency-drill.test.ts should flip on purpose.

Related

• Unknown keys in a where-clause become span-attribute filters. SpanKind = 'Client' used to filter on an attribute named SpanKind, which matches nothing. A first-class span-kind filter would let drills exclude server spans again.