wu-sheng opened a new pull request, #97:
URL: https://github.com/apache/skywalking-horizon-ui/pull/97
## Why
On a Zipkin-tracing layer (mesh / Kubernetes), clicking a trace in the
results list rendered its span waterfall by re-fetching the trace by id
(`/api/zipkin/trace/:id`) — even though Zipkin's `/api/v2/traces` list response
already contains every span for every trace. The BFF was summarising the list
rows and **discarding** those spans, forcing a redundant second round-trip to
OAP for data it already had. (Native BanyanDB traces already ship spans inline
on the list row and render with no re-fetch; this brings Zipkin in line.)
## What
- `ZipkinTraceListRow` gains an optional `spans?: ZipkinSpan[]` (mirrors
`NativeTraceListRow.spans?`).
- `/api/zipkin/traces` keeps the spans it already fetched (`{
...summariseTrace(spans), spans }`) instead of dropping them.
- `LayerZipkinTracesView` renders the inline waterfall from the selected
row's spans, falling back to the by-id fetch only when a selected id isn't in
the current list.
- The `/api/zipkin/trace/:id` route and the popout are **unchanged** —
opening a trace by a pasted id / a shared deep link / a log→trace jump has no
list row and legitimately needs the by-id query.
- The AI-assistant Zipkin list path (`client/zipkin.ts`) is untouched;
`spans` is optional so it simply omits it.
## Validation
- Static gate green: `type-check`, `build` (UI + BFF), `lint` +
source-budget, license headers, 356 unit tests.
- Live public demo OAP (istio/mesh Zipkin data): the list response now
carries `spans` on every row (`spans.length === spanCount`); for a sampled
trace the embedded spans are **byte-identical** to the `/api/zipkin/trace/:id`
detail response; the detail endpoint still returns correctly for the popout.
The inline waterfall renders from the row and the by-id query is gated off when
spans are present. A literal browser network-tab click-through wasn't run —
validated the data contract + gated code path instead.
- No new UI strings (no i18n changes).
--
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]
