Repository navigation
Conversation
…iming page The companion announces each blocking action before it runs and again when it ends, the header shows the running action and the last one, and GET /api/timing returns the companion's actions beside the spans Buckaroo posted back. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…eue and for trace labels Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…a timing page activity.ts holds the pure state: a reducer for action_start and action_end, the now and last labels, the wait a load_expr POST spent in Buckaroo's queue, and the timeline layout. SSEContext keeps it without bumping version; ActivityStrip shows it in the header; TimingPage lays the companion's actions and Buckaroo's spans on one axis. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…burst of activity The rows lacked the flex layout the shared waterfall classes give, and one axis for the whole window made a half-second action a sliver next to another half a minute later. Rows within 2 s of the latest end share an axis. The note on a slow load_expr now says when Buckaroo began handling it, since the gap also holds the request's transfer and parsing, not only queueing. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…em over SSE, and serve /api/timing
tallyman_core/activity.py tracks running and finished actions and tells listeners at each start and end. load_session announces preparing the entry and the load_expr POST; the diff, promote, save-code, reset, staleness and recalc routes announce themselves. The companion forwards the events over SSE and GET /{project}/api/timing returns the actions beside the spans Buckaroo posted back.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a page waits, nothing says what it is waiting on. On 2026-10-08 loading
carstook 3.27 s: the companion's POST to Buckaroo sat for 3.2 s behind a 4.5 s summary-stats run forcamera_violations(Buckaroo runs everything on one IOLoop thread), then Buckaroo's own handler took 39 ms. The activity log has the 3.27 s, andtelemetry.jsonlhas both the stats run and the 39 ms, but nothing puts them side by side.Fix
tallyman_core/activity.py: a process-wide tracker.track(name, detail)tells listeners the action is about to start (action_start) and again when it ends (action_end, with the duration); an exception is recorded as the action's error and re-raised. The companion forwards both over the existing SSE channel (from worker threads, through the loop).prepare entryand thebuckaroo load_exprPOST inBuckarooManager.load_session, and the diff data, promote diff, save code, reset, staleness and recalc routes.now: <action> <detail> · <elapsed>while one runs (the longest,+N morefor the rest),last: <action> <detail> · <time>after, linking to the timing page. SSE action events do not bumpversion, so they do not refetch the catalog.GET /{project}/api/timing?window_s=: the companion's actions and the spans Buckaroo posted back totelemetry.jsonl, on one clock (epoch ms).load_exprPOST says how long after it started Buckaroo began handling it. That gap is queueing plus the request's transfer and parsing; the page does not separate them.Not in this PR: Buckaroo announcing the start of its own work (it posts a span only when it ends, so the header cannot say a stats run is about to start; that needs a change in the buckaroo repo), and actions that run in the MCP process. The log is in memory, so a restart empties it.
Checked in a browser against a running companion: the pill showed
now: buckaroo load_expr 71d4f4fc7932 · 3 msand thenlast: … · 543 ms, and the timing page showed the companion's POST, Buckaroo'sload_expr,ws_first_payloadandstats.completefor it.🤖 Generated with Claude Code