Repository navigation
Dashboard session timeline exhausts work budget on a real project #3210
Description
Activity
The failure also affects a session-specific read: opening the first listed Codex session (478 messages) loads exact session identity/metadata and Git relations, but its transcript returns the same
lcm_temporal_budget_execution_work_exhaustedrefusal. This broadens investigation to the shared temporal retrieval execution path, rather than treating it only as timeline aggregation.The browser console had no JavaScript errors during the successful registry, graph, symbol-search, and caller/callee journey. The UI receives the backend refusal but labels it UNKNOWN with misleading “No response has been recorded” guidance.
Read-only HTTP reproduction through the dashboard’s standard launch-cookie exchange confirms an exact record-count boundary on the same persisted session:
Requested messages Result Elapsed 1 Partial, one canonical message and continuation 258.1 ms 64 Partial, 64 canonical messages and continuation 439.5 ms 65 No payload; execution-work budget refusal 246.9 ms 100 (normal UI page) No payload; execution-work budget refusal 295.6 ms No transcript content was printed or attached. Source investigation found the normal dashboard page size exceeds the existing canonical context record capacity. The temporary browser tab and dashboard server were closed after reproduction. The fix will preserve the budget and use bounded continuation instead.
Backend diagnosis: the canonical temporal context assembler bounds available records at 64 (
context::MAX_CONTEXT_RECORDS), while dashboard session/search/aggregate retrieval admits pages of 100. Context count exhaustion is mapped to the generic execution-work-exhausted reason. Read-only live comparison on the same 478-message session confirms limit 64 returns 64 canonical messages (439.5ms), while limit 65 refuses with execution_work_exhausted (246.9ms); limit 1 succeeds and limit 100 fails. This is a page-shape mismatch, not a wall-time limit. Adding a real dashboard HTTP regression with 70 canonical observations, opaque continuation and timeline aggregation before capping pages at the existing context authority. No budgets are raised.Production-path regression reproduced the exact refusal before the fix: 70 tiny canonical session observations returned null payload and lcm_temporal_budget_execution_work_exhausted (1 failing test). The adapter now caps selection using the existing temporal context MAX_CONTEXT_RECORDS authority (64), retaining the original requested limit in the opaque cursor binding and leaving all byte/work/page budgets unchanged. Afterward the real dashboard fixture serves 64 + 6 messages with 70 unique IDs, then drains both canonical pages into timeline buckets totaling 70. Focused Bazel dashboard tests passed 6/6 and adapter tests passed 7/7; pinned Bazel rustfmt passed on the three owned Rust files. Focused Clippy is running. Installed-artifact verification remains pending the official release.
The dashboard selected up to 100 records per admitted retrieval, while the canonical compact-context assembler accepts at most 64. A real installed session failed at limit65 and succeeded at64; the default request limit100 failed with the same execution-work reason.
The fix uses the existing canonical context maximum before hydration and preserves the original dashboard request plus opaque continuation. It does not increase budgets. An isolated production HTTP regression with70 canonical messages failed before the fix, then passed: default limit100 returns64 records, its cursor returns6 distinct remaining records, and the real timeline buckets count all70.
Bazel verification: six LCM dashboard API tests and seven dashboard adapter tests passed. The UI now distinguishes a received Unknown response from no recorded response while preserving the canonical domain state;26 relevant UI tests and TypeScript checking passed.
The separate478-raw/290-canonical discrepancy remains tracked in #3211. This fix does not claim to resolve that discrepancy or that the installed beta.76 has changed; release and installation are still pending.
Native CI on 9ddae8c passed all 2029 dashboard tests and all six ChatGPT extension adapter tests, then failed the extension's generated-artifact freshness check: plugin/chatgpt-extension/embedded/app.html is stale after the dashboard UI change. The targeted local checks did not cover that committed generated bundle.
I am regenerating it through the existing maintained build entry point and will verify check:embedded before the next push. No generated artifact will be edited by hand, and passing application tests do not need repetition for this output refresh.
Correction to the previous CI update: the ChatGPT extension app does not import the dashboard UI, so the UI change is not an established cause of this freshness failure. Rebuilding the TypeScript SDK prerequisite and then the extension produces artifacts identical to HEAD
9ddae8cb7c; the embedded freshness check also passes locally under Node 22. CI passed 2,029 dashboard tests and six extension tests before reporting staleembedded/app.html. We are investigating the CI input/environment discrepancy; no artifact fix is claimed yet.- added a commit that references this issue
on Oct 9, 2026 - added a commit that references this issue
on Oct 9, 2026
The installed beta.76 dashboard cannot load the TraceDecay project's default message-volume timeline. The session index loads normally (2,703 sessions), but the timeline displays
UNKNOWN · lcm_temporal_budget_execution_work_exhaustedfollowed by “No response has been recorded for this surface yet. Refresh once the daemon is serving.” The daemon is serving: the same dashboard loads code search, source identity, callers/callees, and the session index.Reproduction on Linux using the shipped beta.76 binary:
Expected: bounded work produces the requested timeline or an honest bounded/partial result; typed budget exhaustion must not be described as an unknown/no-response state. Investigate measured work and query shape, not a blind budget increase. Preserve canonical session/redaction authorities and the operator's durable data.
Observed while performing the all-repository installation sweep; no profile wipe or backup was used. The current PR #3200 has not yet been released, so determine whether the production defect remains at its head before changing code.
Current verification: The bounded dashboard retrieval fix is now on master via #3141: requests select at most the canonical 64-record context capacity and aggregates consume opaque continuations within the existing page cap. The real HTTP regression serves 64+6 distinct messages and counts all 70 in the default 400-bucket timeline. Received Unknown responses no longer claim that no response was recorded. The original 2,703-session installed-project journey still needs verification; the small regression alone does not establish its result.
Additional measured repair merged in #3264: a canonical 3,000-session real HTTP regression failed before the prepared-participant join correction (four-second HTTP timeout; SQLite fetch consumed its existing 30-second budget). Keeping bounded requested keys outermost reduced measured participant preparation to 2.93 ms and the traced request to approximately 539 ms. The final integrated regression passed at a630de3 (1 test, 202.75 seconds including fixture creation), as did all 19 participant-authority tests. No budgets or corpus size were relaxed. Temporary tracing was removed. The original installed Linux project journey remains pending, so this issue stays open.
Integrated-master verification at 829bf3e: Bazel ran
loom::default_message_timeline_reports_bounded_counts_for_large_historythrough//crates/tracedecay:dashboard_api_teston native macOS. The canonical 3,000-session fixture and real default daily/400-bucket HTTP request passed (1 passed, 0 failed; 117.81 seconds including fixture creation). Assertions verify nonempty bounded counts and honest complete/partial coverage. This confirms the query repair after the merged schema-admission changes; it does not constitute a replay of the original installed Linux project.