feat: optimize traces list queries to avoid OOM

[Makisuo]

What & Why

tracesListQuery and tracesRootListQuery had the same ClickHouse OOM anti-pattern that was just fixed in logsListQuery (fc4761f75).

The traces sort key is (OrgId, ServiceName, SpanName, toDateTime(Timestamp)) (datasources.ts:213). Because ServiceName and SpanName sit between OrgId and Timestamp, ORDER BY Timestamp DESC is not a sort-key prefix — ClickHouse cannot read-in-order, so it scans the whole org+time window and materializes the heavy SpanAttributes / ResourceAttributes Map(LowCardinality(String), String) columns for every matching span before LIMIT discards all but N. Busy orgs hit the memory limit and the query OOMs.

Fix

Two-stage query, mirroring logsListQuery:

1. Extract baseWhere so stage 1 and stage 2 filter identically (including cursor and, for the root variant, rootOnly).
2. Stage 1 — cheap scan: SELECT Timestamp AS ts FROM traces WHERE … ORDER BY ts DESC LIMIT (limit + offset), compiled via compileCH(inner, {}, { skipFormat: true }) so the outer compile substitutes params once.
   • Only delta from logsListQuery: LIMIT (limit + offset), not just LIMIT limit. Traces support OFFSET for paging; the cutoff must cover every row the outer OFFSET will skip past, not just the slice returned.
3. Stage 2 — heavy projection retained but gated on Timestamp >= (SELECT min(ts) FROM (<cutoffSql>)), so the Map columns / SpanAttributes.get('http.method' …) lookups in the root variant materialize only for rows at/after the cutoff.

Tests

New file packages/query-engine/src/ch/queries/traces.test.ts — 17 tests mirroring the new logsListQuery tests:

• Basic SELECT shape and FORMAT JSON
• Cursor pagination, offset, custom limit
• Filter composition (serviceName, spanName, errorsOnly)
• Attribute-key projection (columns: ["spanAttributes.http.method", …])
• Cutoff subquery shape — Timestamp-only SELECT, ORDER BY ts DESC, LIMIT = limit + offset, no SpanAttributes / Duration materialization
• rootOnly predicate inside the cutoff for the root variant (so the cheap scan matches the same population as the outer query)
• Filters applied identically across both stages (including the cursor predicate, so paginated queries narrow the cheap scan too)

Verification

• bun run test in packages/query-engine — 15 files, 350 tests, all pass
• bun typecheck — all touched packages type-check cleanly (the unrelated @maple/api @maple-dev/effect-sdk/cloudflare error reproduces on a clean main)

Reviewer notes

• No behavior change for callers — same return shape, same filter semantics, same pagination contract.
• The cutoff subquery uses CH.rawExpr because the DSL has no first-class subquery helper for (SELECT min(ts) FROM (…)). Same approach as logsListQuery.
• This change touches only tracesListQuery and tracesRootListQuery. tracesTimeseriesQuery / tracesBreakdownQuery aggregate up front so they don't carry heavy per-row projections — no fix needed there.

🤖 Generated with Claude Code

[pullfrog]

This run croaked 😵

The workflow encountered an error before any progress could be reported. Please check the link below for details.

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ 𝕏}