Operation Dropdown Issue: Extra Characters Added to Operation Names

[dmremre28]

Observation:
I'm experiencing an issue where selecting operations from the Jaeger UI dropdown doesn't return any results, and I've noticed something unusual in the URL parameters.

Jaeger version is: jaeger:2.5.0

What I'm Seeing:
When I select operations from the dropdown, the URLs consistently show unexpected characters at the beginning of operation names:

Example:

Incorrect (with ")" char):
https://jaeger-query.test.com/search?end=1753020659686000&limit=20&lookback=5m&maxDuration&minDuration&operation=%0A%29%2Fv1%2Fapplications%2F%3Aid%2Fworkloads%2Ffilter-set&service=test-api&start=1753020359686000

Expected (without ")" char):
https://jaeger-query.test.com/search?end=1753020659686000&limit=20&lookback=5m&maxDuration&minDuration&operation=%2Fv1%2Fapplications%2F%3Aid%2Fworkloads%2Ffilter-set&service=test-api&start=1753020359686000

The dropdown does show that operations are available, but selecting some of them results in "No trace results." Upon inspecting the URL, it seems that certain operation names are being prepended with unexpected characters such as \n, ), &, or even +. Interestingly, this doesn't happen with all operations—only some are affected. The extra characters appear to be introduced inconsistently, possibly due to a UI encoding or formatting issue.

By the way, we are using the gRPC endpoint feature of Jaeger Query. kindly find the jaeger-query YAML attached.

jaeger-query.txt

Could this be a bug in the UI's dropdown handling? Any insights would be greatly appreciated! 🙏

[dosubot[bot]]

Hi @dmremre28! I'm Dosu and I’m helping the jaeger team.

This isn't a known bug in the Jaeger UI, and there are no existing tickets or discussions tracking this specific issue. The UI displays operation names exactly as it receives them from the backend—there's no sanitization or trimming in the frontend, so any extra characters (like newlines, parentheses, or other symbols) are likely present in the operation names as stored or ingested by the backend or your instrumentation code. This explains why only some operations are affected and why selecting them leads to "No trace results"—the query uses the operation name with those extra characters, which doesn't match any traces.

To resolve this, check your trace ingestion pipeline or backend for sources of these extra characters in operation names. Cleaning or trimming operation names at ingestion or in the backend API is the most robust fix. The UI could defensively trim/sanitize operation names, but this isn't currently implemented as of Jaeger UI 2.5.0.
Source 1
Source 2

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[dmremre28]

Thank you for the quick response and for taking interest in this issue!

You're absolutely right about testing the backend directly. I should have mentioned this upfront - we've actually done comprehensive end-to-end testing on our API endpoints and debugged all the steps:

Backend Testing Results:
✅ Database table level: Operation names are stored clean (no extra characters at the beginning)
✅ gRPC API responses: The operation names returned to jaeger-query UI are clean
✅ Direct API queries: All operation names appear exactly as they should be

What we found:

• The GetOperations() gRPC call returns clean operation names: /v1/applications/:id/workloads/filter-set
• The FindTraces() gRPC call receives malformed operation names: \n)/v1/applications/:id/workloads/filter-set

This appears to be a cosmetic/UI-side issue within jaeger-query UI's dropdown handling, but we're not entirely certain.

Could this be a known issue with the UI's operation dropdown JavaScript/form handling? Or would you recommend any specific debugging steps to isolate where exactly these characters are being introduced?

[yurishkuro]

The FindTraces() gRPC call receives malformed operation names: \n)/v1/applications/:id/workloads/filter-set

If that's the case then it's not the UI, what am I missing?

[yurishkuro]

also which storage are you using?

[dmremre28]

I think I misstated the issue - what I meant is: jaeger-query UI sends malformed operation names to our backend API, which then queries ClickHouse storage with the malformed name and gets "not found" results.

[yurishkuro]

your screenshot was showing malformed names in the dropdown, so it's not like UI makes them up when sending, it happens somewhere when it loads them.