[Bug]: filter by tags not works in Jaeger-UI

[JaredTan95]

What happened?

I want to filter error traces by tags, using error=true can filter out error traces, but using otel.status_code=ERROR will result in an empty query.

Steps to reproduce

This is a screenshot of my trace span content:

I want to filter error traces by tags, using error=true can filter out error traces, but using otel.status_code=ERROR will result in an empty query.

Expected behavior

using otel.status_code=ERROR can query error traces

Relevant log output

Screenshot

No response

Additional context

No response

Jaeger backend version

No response

SDK

No response

Pipeline

No response

Stogage backend

No response

Operating system

No response

Deployment model

No response

Deployment configs

[DCchoudhury15]

/assign

[yurishkuro]

what is otel.status_code? why otel. prefix?

[JaredTan95]

what is otel.status_code? why otel. prefix?

may be exported by otel col otlp-exporter and jaeger-collector converted?

[yurishkuro]

I think otel.status_code is a side effect of translations between Jaeger model and OTLP. It's also used by ES/Cassandra storage implementations to capture OTLP status. So in those storage backends the search should work.

[JaredTan95]

In my case, the Elasticsearch was used.

[DCchoudhury15]

I have opened PR #7760 to address this for the Elasticsearch storage backend.
The root cause was that while otel.status_code is a side effect of OTLP translation, it wasn't actually being persisted as an indexed tag in Elasticsearch (only error=true was stored).
the PR fixes this by adding query translation in the Reader:
When a user searches for otel.status_code="ERROR", the backend will transparently map it to error="true" before executing the query. This ensures it works for both new and historical data without needing to change how data is stored.

[yurishkuro]

When a user searches for otel.status_code="ERROR", the backend will transparently map it to error="true" before executing the query.

I don't like with this approach. The original user data never had an attribute otel.status_code, so they should not be searching for it. The only reason they do is because our translation mechanism leaks this attribute out and it gets displayed in the UI.

[DCchoudhury15]

@yurishkuro , if otel.status_code is a leakage artifact that users shouldn't be searching for, the root problem is that we are persisting it at all.
I have updated the PR to explicitly filter out otel.status_code during ingestion (in to_dbmodel.go).
This should stop the attribute from appearing in the UI for new traces, preventing the user confusion entirely. Does this align with your view on handling the leak?