cncf / cncf/mentoring

[CNCF LFX Proposal] Jaeger OpenTelemetry-Native Query and State Layers Migration

Open
#2,029 15 comments 0 reactions 0 assignees View on GitHub
2026 CNCF Approved Exported lfx mentorship Maintainer/Contribex Approved Mentors Confirmed Proposal Term 3: Sept-Nov Validation Passed
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.