[CNCF LFX Proposal] Jaeger OpenTelemetry-Native Query and State Layers Migration
- Dominant language
- JavaScript
- Stars
- 3.1k
- Forks
- 816
- Avg merge
- 12h 32m
- Merged PRs (30d)
- 8
Description
### CNCF Project
Jaeger
### Term
2026 Term 3 (Sep-Nov)
### Program Name
OpenTelemetry-Native Query and State Layers Migration
### Program Description
## Description
Jaeger UI is two-thirds through three interlocking migrations at different stages. This program finishes all three and deletes what they replaced.
The OpenTelemetry-native move stopped at a deliberate decision point: the UI speaks OTEL vocabulary throughout but obtains it by wrapping the legacy Jaeger model in a facade, and while service discovery and search run on `/api/v3/`, loading a trace still goes over the legacy endpoint and is reshaped in the browser. The state migration is nearly done, largely via community contributions: Redux has given up traces, search results, services, config, and dependencies. One part is not more of the same: the trace timeline dual-writes to Redux and Zustand, because analytics tracking is a Redux middleware keyed on the old action types, so tracking must move before the old slice can go. The target architecture is designed but not built.
The pivotal step is loading a trace natively over `/api/v3/`. Earlier integrations consumed small, flat messages where a generated schema was cheap. A full trace is the first payload that pulls the entire OTLP model into the query layer: nested `resourceSpans`/`scopeSpans`, the recursive `AnyValue` union behind every attribute, events, links, status. Whether that model is generated and validated at the boundary or hand-written is the central judgement. The wire format is its own research task: Jaeger serialises this route differently from a naive protobuf-to-JSON reading, so a parser that guesses wrong passes its fixtures but fails on a real server. Performance is a hard constraint — traces run to 80,000 spans. Everything is gated on it: once traces arrive as OTLP, the facade, the legacy transformer, the legacy types, and the backend's v1 HTTP endpoints lose their reason to exist.
Several contributors already have work open here; refereeing competing approaches and shepherding their PRs to merge is part of the program, and a merged PR the mentee helped land counts as a deliverable met.
Deliverables and design docs are in the upstream issue.
## Expected outcomes
1. **Native OTLP trace loading** — traces load from `/api/v3/traces/{trace_id}` into the enriched domain model, validated at the boundary, with visual and performance parity on a large trace.
2. **Legacy data path deleted** — facade, legacy transformer, and legacy types removed; uploaded OTLP files parsed in the browser; API calls on one client.
3. **Backend follow-through** — v1 HTTP query endpoints in the `jaeger` repo deprecated and removed where policy allows.
4. **Redux fully removed** — reducers migrated to TanStack Query, the timeline's dual write severed by relocating analytics, and the store, provider, and four dependencies deleted.
5. **Unified state architecture implemented** — layout settings resolved by explicit precedence between URL, per-trace heuristics, and stored preferences.
6. **Community pull requests landed rather than bypassed**, with the unblocking decisions recorded.
### Technologies
TypeScript, React, TanStack Query, Zustand, Zod, OpenTelemetry / OTLP, Go, Protobuf, OpenAPI
### Skills same as Technologies?
- [ ] Yes, the required skills are the same as the technologies listed above.
### Required/Desirable Skills
TypeScript, React, refactoring a large codebase without regressing it, TanStack Query, Zustand, Zod, reading specifications (protobuf/OpenAPI/OTLP), basic Go, browser performance profiling, testing discipline, code review
### Mentors
Parship Chowdhury | @parshipcy | parshipchowdhury@gmail.com | parship999
Yuri Shkuro | @yurishkuro | github@ysh.us | yurishkuro
### Upstream Issue URL
https://github.com/jaegertracing/jaeger-ui/issues/4278
### Application Prerequisites
- [x] Resume
- [ ] Cover Letter
- [ ] School Enrollment Verification
- [ ] Participation Permission from school or employer
- [ ] Coding Challenge
- [x] Custom Prerequisite (fill in details below)
### Coding Challenge URL
_No response_
### Custom Prerequisite Name
Project Proposal
### Custom Prerequisite Description
Submit a proposal in your cover letter (see jaegertracing.io/mentorship/applying; PDF preferred). Cover: (1) a wire-format analysis — fetch a trace from `/api/v3/traces/{trace_id}` on a local Jaeger and describe how ids, timestamps, enums, and absent fields are encoded; (2) whether OTLP wire types should be generated and runtime-validated or hand-written, and the trade-off you accept; (3) a migration and deletion plan; (4) how you would engage the pull requests already open; (5) a timeline.
### Custom Prerequisite — File Upload
- [x] Yes — completion of this task requires the mentee to submit a file.
---
**LFX program:** [CNCF - Jaeger: OpenTelemetry-Native Query and State Layers Migration (2026 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/36d66a45-bf3f-4bd2-8032-438436557e11)
Contributor guide
Research direction
Start with the upstream issue and the /api/v3/traces/{trace_id} entry point, then review the existing Jaeger UI query and state migrations and the community pull requests named in the proposal. Done means native OTLP trace loading, removal of the legacy data path and Redux, unified state handling, and any permitted backend endpoint cleanup, with parity and performance for large traces.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, openapi, react, typescript
- Domain
- api, backend, frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100