[detail-app]

Detail bug report: View on Detail

Closes #17

Bug

TracePanel's "Load more spans" badge used trace.span_count as its denominator, but trace.span_count only updates via the polled recent-traces list. When a non-matching search filters the selected trace out of that list, App.tsx falls back to a frozen selection and trace.span_count stops updating. Meanwhile "Load more" fetches from the live spans endpoint whose total reflects the current trace size (a live COUNT(*)), so during active capture + filtered search the badge could render an impossibility like 400 of 250. The header N spans read the same stale value, so the two displays could also disagree.

Fix

In desktop/src/panels.tsx (TracePanel):

• Track a liveTotal state seeded from page.data.total (the first page) and advanced from each more() response's total — the authoritative live span count from the spans endpoint.
• Render the denominator as displayedTotal = Math.max(liveTotal ?? 0, trace.span_count) in both the badge and the header N spans, so the two can't disagree.
• Math.max (not liveTotal ?? trace.span_count) is required: when the polled span_count refreshes past a fetched page's total, the denominator must follow the fresher value. This keeps the existing d9ee901 "200 of 300" assertion intact.
• The useLive page key and the more() in-flight guard key still use trace.span_count (the selection-identity staleness guard) — unchanged. api.ts is untouched.

Testing

• New regression test load-more-stale.test.tsx renders the real App, selects a capture-active trace (capture_status: "collecting"), filters it out with a non-matching xyz search, clicks "Load more" against a grown trace, and asserts the badge reads 400 of 600 with header 600 spans (never 400 of 250). It fails on the unmodified code with the reported message and passes with the fix.
• Existing stale-response tests still pass: d9ee901 keeps the badge at 200 of 300 after the polled span_count advances and drops the stale in-flight more() response; the settled/normal paging test confirms "Load more" disappears at the end and appended spans render.
• Routine checks pass: TypeScript (tsc -b), Prettier, and the full frontend suite (31 tests) are green.
• Backend premises verified against the running ltrace receiver (not mocked): ingesting spans into one trace and reading the spans endpoint confirmed the live total advances under capture (250→600, next_offset 200→400), the run is collecting, and recent_traces?q=xyz excludes the trace while a matching query re-includes it. cargo test --test receiver (10 tests) passes.
• Manual desktop-Tauri UI procedures (end-to-end reproduction, header/badge agreement under the live 2 s poll, search-clear self-heal, cross-trace reset, settled-trace baseline) could not be run: the Tauri app can't build here (missing glib-2.0/webkit2gtk-4.1 system libs, no display/Xvfb), and the frontend can't run in a browser (Tauri IPC + origin-restricted read API). These scenarios are otherwise covered by the component-level reproduction test (pins the rendered 400 of 600 / 600 spans), the existing panels tests (page re-key reset and paging-end button disappearance), and the backend receiver verification above.

---

Automatic Fixes PRs can be configured here.

[nishantmodak]

Approved. The header and Load more badge now use the total returned by the spans endpoint, with the trace summary as a lower bound. This handles a growing trace whose selected summary is stale while preserving the existing pagination response guard. No blocking findings.

Local validation: all 31 desktop tests passed on this head. Frontend, Linux/macOS core, and macOS bundle CI checks pass. Native WebView smoke testing was not run in this review.