Hello, I am milansanjeev

Tell us a bit about yourself before your first pull request. A couple of sentences is plenty.

Who are you?

Sanjeev Verma (@milansanjeev), working at Expedia Group on eg-observe — a paved-road Helm chart that wraps upstream HyperDX for EG's internal observability platform (ClickHouse-backed traces/logs, plus an Okta SSO bridge). Previously introduced in #3048 (vouched via #3049).

What would you like to work on?

#3038 — there's no glanceable total wall-clock duration or span count for a trace as a whole; you have to eyeball the waterfall timeline, and summing individual span durations would double-count parallel/nested work.

PR: https://github.com/hyperdxio/hyperdx/pull/3051

It computes a small aggregate (MIN(start) / MAX(start + duration) / span count) client-side from the span rows DBTraceWaterfallChartContainer already fetches to render the waterfall — no extra query — and renders it next to the existing "N spans, N errors" text in the waterfall's controls bar. Only counts actual spans, not correlated logs, and reflects the whole trace regardless of the waterfall's own show/hide toggles or search filters.

(An earlier revision of this PR put the aggregate on the Search page's Results Table instead, gated on the traceId URL param — moved it here after realizing the search bar's where/filters can diverge from that param while it lingers in the URL, decoupling the displayed rows from the trace scope.)

Anything we can help with?

A look at #3051 when you have a moment — specifically whether computing this client-side from the already-fetched waterfall rows (vs. a separate aggregate query) is the right call, and whether the controls-bar placement is the best spot for it.