[Bug]: ClickHouse ignores the error=true search convention, error filters return nothing

[iammdzaidalam]

What happened?

In #8553 the expectation was stated that "error=true filter is the existing Jaeger convention that is supposed to work regardless of the format of ingested traces. The storage backends receiving OTEL traces directly are expected to still find them via error=true." That thread only ever covered the memory store, which now translates the filter correctly (#9096). ClickHouse does not: the query builder routes the error attribute through ordinary attribute matching, generating arrayExists conditions over the stored attribute maps and never touching the status_code column. OTLP spans carry error state in span status, not in a literal error attribute, so both error=true and error=false return nothing.

I reproduced this against the docker-compose ClickHouse with two traces from one service, one span with status Error and one with status Unset, neither carrying an error attribute. Unfiltered search finds both. With the filter, error=true returns 0 and error=false returns 0. The same setup on the memory store returns 1 and 1.

The data is there: the SPM queries in the same package already compute error rates with countIf(status_code = 'Error'). Only trace search never looks at the column.

Steps to reproduce

1. Write a span with status code Error via OTLP to a ClickHouse-backed Jaeger, without any literal error attribute.
2. Search for that service with error=true (search_traces with_errors, or the UI error filter).
3. The trace is not returned. With error=false it is not returned either.

Expected behavior

error=true finds traces containing a span with status Error, and error=false finds the complement including Unset status spans, matching the memory store semantics from #9096. The natural place is the ClickHouse query builder, translating the error attribute into a status_code predicate instead of attribute matching.

Relevant log output

# live repro against docker-compose ClickHouse, two traces (Error + Unset), no error attributes
unfiltered      -> 2 traces
error=true      -> 0 traces
error=false     -> 0 traces

Screenshot

No response

Additional context

Related: #8553 (the convention and the memory-store case), #9096 (error=false must include Unset spans). Filed separately since #8553's thread and its open PR cover the memory store only.

Jaeger backend version

v.2.20.0

SDK

Any

Pipeline

OTLP -> Jaeger v2 -> ClickHouse. The bug is in the read path, the query builder

Stogage backend

Clickhouse (docker-compose/clickhouse, server 25.12)

Operating system

MacOS

Deployment model

No response

Deployment configs

[Udaytaneja]

Hi mantainers @iammdzaidalam , I'm interested in doing this work. Please assign this to me.

[iammdzaidalam]

Hi @Udaytaneja, thanks for showing interest but work is already being done on this one.