cmoriarty/braid
1
0
Fork 0
Code Issues 15 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Step pane: context card and session chip ignore a budget respawn #57

New issue
Closed
opened 2026-09-26 18:16:41 -04:00 by cmoriarty · 1 comment
cmoriarty commented 2026-09-26 18:16:41 -04:00
Owner
Copy link

Seen on production run run_01M3FS9FFXEHTY5WTHX36V4Z5Y, step fix.implement (stp_01M3FS9JXBQJN4A21P8HBWMY0S), after attempt 1 hit the 196k alarm and respawned once.

The engine did the right thing: the handoff happened, and a fresh session (ses_f20430c…) carried on at about 28k and is growing normally. The step pane still reports the attempt as if nothing had changed. Two display problems:

1. The context card shows the attempt's peak as though it were the current context

The graph row reads the live digest, which is the current session's context (28k). The step pane card, labelled "Attempt 1 · context 196k of 252k" with an orange bar at 78%, reads budget_ledger.peak_input_tokens through readingOf (ui/src/lib/budget.ts). That value is the attempt's high-water mark across every session it has had, and it never resets on a respawn (by design, see on_respawn in src/osf/engine/budget.py).

The two panes then disagree (28k vs 196k), and the card reads as if the step were nearly full just after a respawn emptied it. "CONTEXT 196k" next to "ALARM 196k" makes it worse.

Want: while a step is running, the card shows the live reading of the current session, and it agrees with the graph row. The attempt's peak and its respawns stay visible, labelled as the peak.

2. The attempt's session chip names the retired session

The attempt row shows session 5pj0YKlr, which is the pre-respawn session. attempt.session_id keeps the first session id. The digest already follows osf.budget.respawned to the session actually in use (_RESPAWNED_TO_SQL in src/osf/engine/digest.py), but the step pane does not.

Want: after a respawn, the attempt chip names the session the attempt is actually using.

Seen on production run `run_01M3FS9FFXEHTY5WTHX36V4Z5Y`, step `fix.implement` (`stp_01M3FS9JXBQJN4A21P8HBWMY0S`), after attempt 1 hit the 196k alarm and respawned once. The engine did the right thing: the handoff happened, and a fresh session (`ses_f20430c…`) carried on at about 28k and is growing normally. The step pane still reports the attempt as if nothing had changed. Two display problems: ### 1. The context card shows the attempt's peak as though it were the current context The graph row reads the live digest, which is the **current** session's context (28k). The step pane card, labelled "Attempt 1 · context 196k of 252k" with an orange bar at 78%, reads `budget_ledger.peak_input_tokens` through `readingOf` (`ui/src/lib/budget.ts`). That value is the attempt's high-water mark across every session it has had, and it never resets on a respawn (by design, see `on_respawn` in `src/osf/engine/budget.py`). The two panes then disagree (28k vs 196k), and the card reads as if the step were nearly full just after a respawn emptied it. "CONTEXT 196k" next to "ALARM 196k" makes it worse. **Want:** while a step is running, the card shows the live reading of the current session, and it agrees with the graph row. The attempt's peak and its respawns stay visible, labelled as the peak. ### 2. The attempt's session chip names the retired session The attempt row shows `session 5pj0YKlr`, which is the pre-respawn session. `attempt.session_id` keeps the first session id. The digest already follows `osf.budget.respawned` to the session actually in use (`_RESPAWNED_TO_SQL` in `src/osf/engine/digest.py`), but the step pane does not. **Want:** after a respawn, the attempt chip names the session the attempt is actually using.
cmoriarty commented 2026-09-26 19:13:06 -04:00
Author
Owner
Copy link

Shipped in #61 (d8f447a) and archived as step-pane-follows-respawn (2465b85).

  • Context card: while a step is running, the bar and the context field read the same live digest frame as the graph row, so the two now agree. The attempt's high-water mark is its own peak field, with an ⓘ. A finished attempt that respawned labels its figure peak rather than context.
  • Session chip: it names the session the attempt is using now, and an ⓘ names the session it started on. GET /api/steps/{id} gains current_session_id on each attempt (the latest osf.budget.respawned to_session, null without one). session_id is unchanged, because recovery asks about it.
  • Spec: step-details is updated with the running-after-respawn, finished-after-respawn and session-chip scenarios.
Shipped in #61 (`d8f447a`) and archived as `step-pane-follows-respawn` (`2465b85`). - **Context card:** while a step is running, the bar and the `context` field read the same live digest frame as the graph row, so the two now agree. The attempt's high-water mark is its own `peak` field, with an ⓘ. A finished attempt that respawned labels its figure `peak` rather than `context`. - **Session chip:** it names the session the attempt is using now, and an ⓘ names the session it started on. `GET /api/steps/{id}` gains `current_session_id` on each attempt (the latest `osf.budget.respawned` `to_session`, `null` without one). `session_id` is unchanged, because recovery asks about it. - **Spec:** `step-details` is updated with the running-after-respawn, finished-after-respawn and session-chip scenarios.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
archive/prefect-kestra-experiments
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cmoriarty/braid#57
No description provided.