Files
Karthik Kalyan 1280163551 Use the storage APIs for run detail views (#3944)
* Fix empty trace and events tabs on older runs

A run's events were read from a different source than the rest of the run
detail view, one with a shorter retention window and a small ingestion
delay. Past that window the trace and events tabs came up empty even
though the run's data was still retained, and the events tab's own id
search would find events the list above it was not showing. Inside the
window, a run still executing could show gaps.

All the run-scoped reads now come from the same source as the rest of the
view. The runs list and hooks list are unchanged: they span runs and are
fine where they are.

The events tab's id search now stops after fewer pages before reporting a
truncated result.

Removes the fetchSteps server action and its /api/rpc method. The trace
viewer has built its spans from events since the observability
data-fetching refactor, which left fetchSteps the only /api/rpc method
with no caller.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Describe the read paths without backend internals

The comments explaining why these reads moved named the plan field that
gates the analytics window, its per-plan day counts, storage TTLs, index
choices and page-scan mechanics. This repo is the client SDK, so those
belong on the service side, not here — the reason a caller needs is that
the analytics namespace is a metadata mirror with a shorter retention
window and asynchronous ingestion.

Also drops the claim that this listing feeds the graph tab, which is
disabled in run-detail-view.tsx.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 12:18:38 -07:00
..