Skip to content

fix: report the rollout's timings when the server ends the run - #8

Merged
tactino merged 1 commit into
mainfrom
fix/report-timings-on-server-stop
Sep 13, 2026
Merged

tactino merged 1 commit into
mainfrom
fix/report-timings-on-server-stop

Conversation

@tactino

@tactino tactino commented Sep 13, 2026

Copy link
Copy Markdown
Member

rollout() logs a final timing summary when its loop finishes. The loop also ends the other way: the server takes the last step it was asked for, closes with plugrl-server-stop, and the agent raises ServerStopped out of an infer. run() already treats that as the happy path — the comment there records that it used to escape as an unhandled exception and end a successful run in a traceback.

It was not happy enough. The exception left rollout() before the summary, so a run that ended exactly as intended reported no timings at all.

Why that matters more than timings

env_steps in that line is the only client-side record of how far the rollout got, and it is what a server's global_step has to be reconciled against. Without it there is no way to tell whether the two sides agree about how much work happened.

How it was found

Building E9, whose entire point is that reconciliation across several clients at once. The harness read the step count from a log line that a normal finish never printed, so every run looked like it had taken zero steps and every row failed its own validity check.

The fix

The summary now runs in a finally, so it belongs to the rollout however the rollout ends.

Tests

tests/test_rollout_reports_on_server_stop.py drives the real loop rather than a stand-in, because the defect was in an exit path and a mocked rollout has none. Verified both fail against the previous behaviour: one finds no summary at all, the other finds no step count in it.

141 passed, 11 skipped. ruff check --exclude third_party . clean.

🤖 Generated with Claude Code

`rollout()` logs a final timing summary when its loop finishes. The loop also
ends the other way: the server takes the last step it was asked for, closes
with plugrl-server-stop, and the agent raises ServerStopped out of an infer.
`run()` already treats that as the happy path - the comment there records that
it used to escape as an unhandled exception and end a successful run in a
traceback.

It was not happy enough. The exception left rollout() before the summary, so a
run that ended exactly as intended reported no timings at all. What went with
them matters more than the timings: env_steps is the only client-side record
of how far the rollout got, and it is what a server's global_step has to be
reconciled against. Without it there is no way to tell whether the two sides
agree about how much work happened.

Found while building E9, whose whole point is that reconciliation across
several clients. The harness read the count from a log line that a normal
finish never printed, so every run looked like it had taken zero steps.

The summary now runs in a finally, so it belongs to the rollout however the
rollout ends.

Tests drive the real loop rather than a stand-in, because the defect was in an
exit path and a mocked rollout has none. Both fail against the previous
behaviour: one finds no summary at all, the other finds no step count in it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
@tactino
tactino merged commit 70fbdc1 into main Sep 13, 2026
2 checks passed
@tactino
tactino deleted the fix/report-timings-on-server-stop branch September 13, 2026 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant