fix(storage/v2): Use FindTraceIDsRequest for FindTraceIDs RPC#8603
Conversation
Sync the idl submodule to the fix-find-trace-ids-request branch which introduces a dedicated FindTraceIDsRequest type. Update the gRPC handler, client, and their tests accordingly. Relates to jaegertracing/jaeger-idl#200 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Yuri Shkuro <github@ysh.us>
There was a problem hiding this comment.
Pull request overview
Aligns the storage/v2 gRPC API with the “one RPC = one request message” convention by switching the FindTraceIDs RPC to use the newly introduced FindTraceIDsRequest message (wire-compatible with the previous FindTracesRequest payload), and updates the Jaeger gRPC storage client/server code plus tests accordingly.
Changes:
- Update the v2 gRPC trace reader client to call
FindTraceIDswithFindTraceIDsRequest. - Update the v2 gRPC storage handler and related tests to accept
FindTraceIDsRequest. - Regenerate/update v2 protobuf Go bindings to include
FindTraceIDsRequestand update theFindTraceIDsmethod signatures.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| internal/storage/v2/grpc/tracereader.go | Client now invokes FindTraceIDs using FindTraceIDsRequest. |
| internal/storage/v2/grpc/tracereader_test.go | Test server signature updated to match new RPC request type. |
| internal/storage/v2/grpc/handler.go | Handler FindTraceIDs RPC now accepts *FindTraceIDsRequest. |
| internal/storage/v2/grpc/handler_test.go | Handler test updated to send FindTraceIDsRequest. |
| internal/proto-gen/storage/v2/trace_storage.pb.go | Generated bindings updated to add FindTraceIDsRequest and adjust service interfaces accordingly. |
Files not reviewed (1)
- internal/proto-gen/storage/v2/trace_storage.pb.go: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8603 +/- ##
==========================================
+ Coverage 96.57% 96.60% +0.02%
==========================================
Files 331 331
Lines 17566 17566
==========================================
+ Hits 16965 16969 +4
+ Misses 453 450 -3
+ Partials 148 147 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
v0.8.0 introduces FindTraceIDsRequest as a dedicated request type for the FindTraceIDs RPC in storage/v2/trace_storage.proto. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Yuri Shkuro <github@ysh.us>
CI Summary ReportMetrics Comparison❌ 36 metric change(s) detected View changed metricsFor label-level diff details, open the CI run and expand the "Compare metrics and generate summary" step logs. metrics_snapshot_elasticsearch_9.x_e2e — ⬇️ download diff
Code Coverage✅ Coverage 97.3% (baseline 97.3%) ➡️ View CI run | View publish logs |
## Summary - Make PR metrics comparison non-blocking when snapshot diffs are found. - Keep metrics infra/reporting failures blocking when diff artifacts are missing or totals cannot be read. - Render metric diffs as warning/informational in PR comments and check summaries. ## Context Recent PRs have been blocked by flaky metric snapshot diffs unrelated to the PR changes. For example, PR #8603 had all CI jobs pass, then failed Metrics Comparison because one Elasticsearch 9.x E2E snapshot observed transient FindTraces error-path series while the other did not. This preserves visibility into metric diffs without making unrelated PRs depend on deterministic runtime metric presence. ## Follow-ups - Add explicit exclusions for known nondeterministic error-path series, such as jaeger_storage_requests/latency with result=err and rpc_server_call_duration with UNKNOWN/non-OK status. - Make hard metric gating opt-in through a label or path-based trigger for telemetry/metrics-sensitive changes. - Stabilize the E2E metric snapshot source by making the tests wait for backend readiness before query retries or by deliberately exercising a deterministic set of success/error paths before scraping. - Consider retry/quorum semantics for metrics diffs, rerunning only the affected E2E matrix entry before reporting a blocking failure. - Move hard metric snapshot gating to main/nightly/release validation while keeping PR-level reporting informational. ## Testing - npm test -- ci-summary-report-publish.test.js - make fmt - make lint - make test Note: make lint and make test needed to be rerun with normal local access because the sandbox blocked the Go build cache and local test listeners. Signed-off-by: Yuri Shkuro <github@ysh.us>
… results (#8604) ## Summary - Part of #8606 Implements Milestone 1 from ADR-010 (#8602): a working `GET /api/v3/trace-summaries` HTTP endpoint backed by fallback aggregation, entirely within `jaeger/` with no `jaeger-idl` changes. - **`tracestore.TraceSummary` / `ServiceSummary`** types and optional **`tracestore.SummaryReader`** interface (`internal/storage/v2/api/tracestore/summary.go`) — existing storage implementations require no changes - **`querysvc.FindTraceSummaries`** with fallback: type-asserts to `SummaryReader`; if absent, calls `FindTraces` and computes summaries via `computeSummaries` (`querysvc/summary.go`) - **`GET /api/v3/trace-summaries`** HTTP handler (`apiv3/http_gateway.go`), reusing the existing query-parameter parser from `FindTraces`; response is plain JSON (proto formalisation is Milestone 3) - Unit tests: `computeSummaries` (empty, error, multi-service with per-service error counts), `FindTraceSummaries` (fallback path + native `SummaryReader` path), HTTP handler (success + storage error) ## Response shape Timestamps are Unix nanoseconds encoded as **decimal strings**, consistent with OTLP proto3 JSON encoding (`startTimeUnixNano` in `GET /api/v3/traces`). String encoding avoids float64 precision loss in JavaScript for values above 2⁵³ (~9×10¹⁵); nanosecond timestamps (~1.7×10¹⁸) are well above that threshold. Duration is intentionally omitted — callers derive it as `BigInt(maxEndTimeUnixNano) - BigInt(minStartTimeUnixNano)`. ```json { "summaries": [ { "traceID": "00000000000000000000000000000001", "rootServiceName": "frontend", "rootOperationName": "HTTP GET /", "minStartTimeUnixNano": "1000000000000000000", "maxEndTimeUnixNano": "1001000000000000000", "spanCount": 3, "errorSpanCount": 1, "orphanSpanCount": 0, "services": [ {"name": "backend", "spanCount": 1, "errorSpanCount": 0}, {"name": "frontend", "spanCount": 2, "errorSpanCount": 1} ] } ] } ``` ## Example ``` curl 'http://localhost:16686/api/v3/trace-summaries?query.service_name=frontend&query.start_time_min=2026-05-21T23:00:00Z&query.start_time_max=2026-05-22T00:00:00Z&query.num_traces=20' ``` ## Test plan - [x] `make fmt lint` — clean - [x] `go test ./cmd/jaeger/internal/extension/jaegerquery/...` — all pass - [x] Manual smoke test with `curl` against a running Jaeger-all-in-one — returns correct summaries ## Related - ADR-010: #8602 - IDL cleanup: #8603 - UI PR: jaegertracing/jaeger-ui#3941 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Yuri Shkuro <github@ysh.us> Signed-off-by: Yuri Shkuro <yurishkuro@users.noreply.github.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
…tracing#8603) ## Summary `FindTraceIDs` in `storage/v2/trace_storage.proto` was reusing `FindTracesRequest` as its argument type, inconsistent with the schema convention that each RPC has its own request struct. This PR: - Syncs the `idl` submodule to jaegertracing/jaeger-idl#200, which introduces `FindTraceIDsRequest` (same field layout as `FindTracesRequest`, wire-compatible, source-breaking rename) - Updates the gRPC storage handler (`internal/storage/v2/grpc/handler.go`) and client (`tracereader.go`) to use `FindTraceIDsRequest` - Updates the corresponding tests ## Related - jaegertracing/jaeger-idl#200 — proto change (must merge first) - jaegertracing#8602 — ADR-010 Trace Summary API (where this cleanup was identified) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Yuri Shkuro <github@ysh.us> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Victor Chidera Obiezue <obiezuechidera@gmail.com>
## Summary - Make PR metrics comparison non-blocking when snapshot diffs are found. - Keep metrics infra/reporting failures blocking when diff artifacts are missing or totals cannot be read. - Render metric diffs as warning/informational in PR comments and check summaries. ## Context Recent PRs have been blocked by flaky metric snapshot diffs unrelated to the PR changes. For example, PR jaegertracing#8603 had all CI jobs pass, then failed Metrics Comparison because one Elasticsearch 9.x E2E snapshot observed transient FindTraces error-path series while the other did not. This preserves visibility into metric diffs without making unrelated PRs depend on deterministic runtime metric presence. ## Follow-ups - Add explicit exclusions for known nondeterministic error-path series, such as jaeger_storage_requests/latency with result=err and rpc_server_call_duration with UNKNOWN/non-OK status. - Make hard metric gating opt-in through a label or path-based trigger for telemetry/metrics-sensitive changes. - Stabilize the E2E metric snapshot source by making the tests wait for backend readiness before query retries or by deliberately exercising a deterministic set of success/error paths before scraping. - Consider retry/quorum semantics for metrics diffs, rerunning only the affected E2E matrix entry before reporting a blocking failure. - Move hard metric snapshot gating to main/nightly/release validation while keeping PR-level reporting informational. ## Testing - npm test -- ci-summary-report-publish.test.js - make fmt - make lint - make test Note: make lint and make test needed to be rerun with normal local access because the sandbox blocked the Go build cache and local test listeners. Signed-off-by: Yuri Shkuro <github@ysh.us> Signed-off-by: Victor Chidera Obiezue <obiezuechidera@gmail.com>
… results (jaegertracing#8604) ## Summary - Part of jaegertracing#8606 Implements Milestone 1 from ADR-010 (jaegertracing#8602): a working `GET /api/v3/trace-summaries` HTTP endpoint backed by fallback aggregation, entirely within `jaeger/` with no `jaeger-idl` changes. - **`tracestore.TraceSummary` / `ServiceSummary`** types and optional **`tracestore.SummaryReader`** interface (`internal/storage/v2/api/tracestore/summary.go`) — existing storage implementations require no changes - **`querysvc.FindTraceSummaries`** with fallback: type-asserts to `SummaryReader`; if absent, calls `FindTraces` and computes summaries via `computeSummaries` (`querysvc/summary.go`) - **`GET /api/v3/trace-summaries`** HTTP handler (`apiv3/http_gateway.go`), reusing the existing query-parameter parser from `FindTraces`; response is plain JSON (proto formalisation is Milestone 3) - Unit tests: `computeSummaries` (empty, error, multi-service with per-service error counts), `FindTraceSummaries` (fallback path + native `SummaryReader` path), HTTP handler (success + storage error) ## Response shape Timestamps are Unix nanoseconds encoded as **decimal strings**, consistent with OTLP proto3 JSON encoding (`startTimeUnixNano` in `GET /api/v3/traces`). String encoding avoids float64 precision loss in JavaScript for values above 2⁵³ (~9×10¹⁵); nanosecond timestamps (~1.7×10¹⁸) are well above that threshold. Duration is intentionally omitted — callers derive it as `BigInt(maxEndTimeUnixNano) - BigInt(minStartTimeUnixNano)`. ```json { "summaries": [ { "traceID": "00000000000000000000000000000001", "rootServiceName": "frontend", "rootOperationName": "HTTP GET /", "minStartTimeUnixNano": "1000000000000000000", "maxEndTimeUnixNano": "1001000000000000000", "spanCount": 3, "errorSpanCount": 1, "orphanSpanCount": 0, "services": [ {"name": "backend", "spanCount": 1, "errorSpanCount": 0}, {"name": "frontend", "spanCount": 2, "errorSpanCount": 1} ] } ] } ``` ## Example ``` curl 'http://localhost:16686/api/v3/trace-summaries?query.service_name=frontend&query.start_time_min=2026-05-21T23:00:00Z&query.start_time_max=2026-05-22T00:00:00Z&query.num_traces=20' ``` ## Test plan - [x] `make fmt lint` — clean - [x] `go test ./cmd/jaeger/internal/extension/jaegerquery/...` — all pass - [x] Manual smoke test with `curl` against a running Jaeger-all-in-one — returns correct summaries ## Related - ADR-010: jaegertracing#8602 - IDL cleanup: jaegertracing#8603 - UI PR: jaegertracing/jaeger-ui#3941 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Yuri Shkuro <github@ysh.us> Signed-off-by: Yuri Shkuro <yurishkuro@users.noreply.github.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Victor Chidera Obiezue <obiezuechidera@gmail.com>
Summary
FindTraceIDsinstorage/v2/trace_storage.protowas reusingFindTracesRequestas its argument type, inconsistent with the schema convention that each RPC has its own request struct.This PR:
idlsubmodule to fix(storage/v2): Give FindTraceIDs its own request type jaeger-idl#200, which introducesFindTraceIDsRequest(same field layout asFindTracesRequest, wire-compatible, source-breaking rename)internal/storage/v2/grpc/handler.go) and client (tracereader.go) to useFindTraceIDsRequestRelated
🤖 Generated with Claude Code