wu-sheng opened a new pull request, #43:
URL: https://github.com/apache/skywalking-mcp/pull/43
## Problem
Fixes apache/skywalking#13939.
`query_traces` only used the trace-**v2** GraphQL API (`queryTraces`), which
is **BanyanDB-only**. On Elasticsearch/JDBC storages and older OAP releases it
fails:
- OAP 10.2 (no trace-v2 in schema): `Validation error
(FieldUndefined@[queryTraces]): Field 'queryTraces' in type 'Query' is
undefined`
- OAP with trace-v2 but non-BanyanDB storage: `Only BanyanDB storage support
Trace V2 query now`
The tool had no way to tell which protocol the backend supports.
## Fix
Detect backend capability via the `hasQueryTracesV2Support` field, then
route:
- **v2 supported** (BanyanDB) → existing `queryTraces` path, unchanged.
- **v2 unsupported** (Elasticsearch/JDBC, or field absent on older OAP →
treated as unsupported) → legacy **v1** path: `queryBasicTraces` + per-trace
`queryTrace`, assembled into the same `TraceList` shape so the summary /
errors_only / full views work identically.
`hasQueryTracesV2Support` and `queryTraces` were introduced together in OAP,
so a backend has both or neither — any detection error safely falls back to v1.
### Note on the `queryTrace` `duration` argument
It is omitted deliberately. `duration` is BanyanDB-only and does **not**
exist on OAP < 10.3.0, so including it would break the fallback on exactly the
older, non-BanyanDB backends this path targets (`Unknown argument 'duration'`).
Non-BanyanDB storages look a trace up by ID across all indices regardless.
### Known limitation (documented in code + tool description)
On non-BanyanDB storages `queryBasicTraces` paginates over trace *segments*,
so `page_size` bounds segments, not whole traces; segments of the same
distributed trace are de-duplicated here by trace ID, so a broad query may
return fewer than `page_size` traces. Narrowing by service/endpoint keeps the
ratio ~1:1.
## Testing
- **Unit tests** (`trace_test.go`, mock GraphQL server): v1↔v2 routing,
segment→trace dedup, and a regression guard asserting the v1 query never
carries `duration`.
- **Live BanyanDB** (public demo): detection → `true` → v2 path returns real
data end-to-end through the built binary.
- **Live Elasticsearch** (repo's `test/e2e-v2/cases/storage/es`, OAP master
+ ES 8.18.8 + provider/consumer apps):
- Reproduced the bug: `queryTraces` on ES → `Only BanyanDB storage support
Trace V2 query now`.
- `hasQueryTracesV2Support` on ES → `false`.
- Built `swmcp` end-to-end → v1 path → real traces: `summary` view
returned 10 traces across both services; `full` view assembled a complete
10-span cross-service trace (correct `CROSS_PROCESS` refs), confirming dedup.
`make build`, `make lint`, unit tests, and license header check all pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
