Repository navigation
Command details take ~35s because every read re-parses historical Session traces #1363
Description
This was generated by AI during triage.
Command details in the Console stay on "Loading details…" for about 35 seconds on every Command, and thirdshift show <command> --json and thirdshift metrics --json take just as long. Every read that loads Run metrics re-parses the Session trace of each Command that ended before #1037, and keeps nothing, so each pane open, live refresh and metrics call pays the whole cost again.
Reproduction
On the stephens host with thirdshift 0.16.1, and again on main at 21e8b5b4:
thirdshift show <command> --jsonpassed a 30-60s timeout forsecure-20261025T063021-0400(JacobStephens2/voice-agent-scheduling),secure-20261025T033012-0400,secure-20261025T050021-0400andpickup-20261025T145901-0400.thirdshift metrics --jsondid the same.thirdshift status --jsonreturns immediately, so it only happens on the Run metrics load.- The process sits at ~100% CPU with no children, so it is not waiting on GitHub.
Measurement
With temporary timing around each session_signals::read call in a release build of 21e8b5b4, one thirdshift metrics --json took 34.6s, and 34.3s of that was 562 Session trace reads. The logs directory holds 1,750 .jsonl files (8.2G). No single file is the problem: the slowest read was 0.87s, most were 0.2-0.5s.
Cause
Snapshot::load_metrics_with_silence reads records with past_metrics: true. For each record whose RunMetrics has no session_signals, either a pre-#1037 record or a historical reconstruction, RunMetrics::add_session_signals calls session_signals::read on every stage's Session trace. Records completed after #1037 (b59894e0, 2026-10-23) store their signals and skip this step. The record cache keeps parsed records only, not signals.
The Console's loadPeek fetch has no timeout, so the pane shows "Loading details…" until the response arrives.
Activity
JacobStephens2 commentedon Oct 26, 2026
Agent Brief
Category: bug
Summary: Command details and Run metrics re-parse every historical Session trace on each read, so each request takes ~35s
Current behavior:
Any read that loads a Snapshot with past Run metrics (Console Command details via
/peek,thirdshift show,thirdshift metrics) callsRunMetrics::add_session_signalsfor every Command whose storedRunMetricshas nosession_signals. That parses each stage's Session trace withsession_signals::read. On a host with 562 such Session traces this takes ~34s per request, and nothing is kept between requests. A Console pane open plus its live refreshes repeat the cost every time.Desired behavior:
stop::inspect, theshowpath) read Session signals only for the Command being shown and its dispatched records. Usual ranges and every other Command's health must stay the same.thirdshift metrics) parse each Session trace at most once while it is unchanged. Keep derivedSessionSignalskeyed on the trace's identity (path plus length and modification time, or something equally strict), the same way the parsed-record cache keys records. A trace that changes or is still being written must be read again, never served stale.RunMetricsalready hassession_signalsbehave exactly as they do now.Key interfaces:
Snapshot::load_metrics_with_silence/load_metricsand thepast_metricsflag on record reading: decide which records need Session signals, not just whether.RunMetrics::add_session_signals(record, read): itsreadclosure is where a memoized reader slots in.session_signals::read(&Path) -> Result<Option<SessionSignals>>: unchanged contract; results become cacheable.stop::inspect(&UserConfig, &str) -> Inspection: should no longer cost one parse per historical Session trace.Acceptance criteria:
session_signals) shows Command details for one Command calls the Session-signal reader only for that Command's own Session traces.thirdshift metrics --jsonreport for a historical Command match what they report today (same JSON for the same fixtures).thirdshift show <command> --jsonreturns in under 1s, and so does opening Command details in the Console.Out of scope:
session_signals::readitself, beyond what caching needs.thirdshift status, which do not load past Run metrics.JacobStephens2 commentedon Oct 26, 2026
Retrying on codex. Earlier Runs failed on codex capacity errors (05:01, 09:14), and the 09:30 grok Run's diagnosis ended without a reproduced or not reproduced line. Branch
issue-1363and draft PR #1377 are reused.