fix(query): sort api_v3 GetDependencies links by parent then child - #9513
fix(query): sort api_v3 GetDependencies links by parent then child#9513samuel7james wants to merge 1 commit into
Conversation
QueryService.GetDependencies builds its result from a map, so apiv3.Handler.GetDependencies returned the same links in a different order on repeated identical calls. The legacy HTTP handler (jaegertracing#9119) and the MCP get_service_dependencies tool (jaegertracing#8403) already sort their dependency links this way; the gRPC api_v3 path was the one place still unsorted. Sorts by Parent then Child with slices.SortFunc/cmp.Compare, matching the other two paths. Signed-off-by: Samuel James <samuel7james@gmail.com>
|
Hi @samuel7james, thanks for your contribution! To ensure quality reviews, we limit how many concurrent PRs new contributors can open:
This PR is currently on hold. We will automatically move this into the review queue once your existing PRs are merged or closed. Please see our Contributing Guidelines for details on our tiered quota policy. |
There was a problem hiding this comment.
🟢 Approval recommended
The focused implementation matches the issue requirements and includes effective regression coverage.
Pull request overview
Ensures deterministic api_v3 dependency responses by sorting links by parent, then child.
Changes:
- Adds canonical dependency sorting.
- Adds regression coverage for unsorted storage results.
File summaries
| File | Description |
|---|---|
grpc_handler.go |
Sorts dependency links before response conversion. |
grpc_handler_test.go |
Verifies parent/child ordering. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
there is already an identical earlier PR #9127 |
|
Closing — you're right, this duplicates #9127, which was already open. Apologies for not checking for an existing PR before starting. #9127 also has your architectural feedback to work from (sorting belongs in QueryService, not duplicated per-transport), which is the better place to continue this fix. |
Which problem is this PR solving?
Description of the changes
QueryService.GetDependenciesbuilds its result from a Go map, soapiv3.Handler.GetDependencies(the gRPC api_v3 path) returned the same set of dependency links in a different order on repeated identical calls.get_service_dependenciestool in [jaegermcp] Add get_service_dependencies tool #8403. This closes the third path the issue calls out as still unsorted.ParentthenChildwithslices.SortFunc/cmp.Compare, the same comparator shape fix(dep): fix nondeterministic dependency ordering #9119 used for the legacy handler.How was this change tested?
TestGetDependencies_SortedByParentThenChild, which feeds the mock storage layer three links in an order that isn't recoverable by insertion order or byCallCount, so it only passes if the handler actually sorts.go test ./cmd/jaeger/internal/extension/jaegerquery/internal/apiv3/...— all pass, including the pre-existingTestGetDependencies,TestGetDependenciesStorageError, andTestHTTPGatewaysnapshot tests in that package.golangci-lint run ./cmd/jaeger/internal/extension/jaegerquery/internal/apiv3/...— 0 issues.gofmt -landgo veton both changed files — clean.make lint test, since the change itself only touches this one file pair.Checklist
make lint testAI Usage in this PR (choose one)
See AI Usage Policy.