Files
werkrevisor/docs/prs/2026-10-17-PR#120-codex-timer-1min.md
claude-code 698762f900
werkator build succeeded after 00:11
werkator/werkrevisor-statistics build succeeded after 00:29
werkator/release build succeeded after 00:14
werkrevisor 0.47.1: the Codex runner starts 1 minute after its last run (#120)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-17 14:56:50 +02:00

43 lines
1.9 KiB
Markdown

# PR#120: The Codex Runner Starts 1 Minute after Its Last Run
Version: patch
> **WARNING:** This document describes only the change applied in this PR.
> It may already be outdated once the next PR is merged.
> Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.
## Related Links
- [PR#88](2026-10-11-PR#88-codex-runner.md): the Codex runner and its systemd units.
## Problem
The timer starts the Codex runner 5 minutes after the end of its last run (`OnUnitInactiveSec=5min`).
Over the 49 Codex reviews since 2026-10-10, the time from the werkrevisor result to the Codex result
has a median of 3.4 minutes and a p90 of 6.5 minutes; most of it is the gap of the timer.
A run without a ready PR takes about 5 s and 2 s CPU.
## Non-Goals
- No parallel reviews: they would save about 1 minute in rare cases,
and `attempts.json` and the fetches of the mirrors would need locks.
- No change of the installed unit on the workstation; the human installs it after the merge.
## Solution
- `tools/systemd/werkrevisor-codex-runner.timer`: `OnUnitInactiveSec=1min`.
- `config/codex-runner.toml`: `max_reviews_per_run = 1`.
- The docstring of `tools/codex-runner`, the README and the config name the new interval
and the new purpose of `max_reviews_per_run`.
- Version 0.47.1.
## Open Questions
- [x] Does `max_reviews_per_run = 3` still fit a run each minute?
No; it is now 1.
The quota of the subscription is weekly, so the bound per run does not change the total use.
The bound now limits how old the view of a run gets: the runner reviews the heads it saw at its start,
and a review takes several minutes, so the third review of a run could review a head that a push already replaced.
With 1 review per run, the next run starts 1 minute later and sees the current heads.
A backlog of several ready PRs costs 1 minute more per PR; only 4 of 45 runs had a second ready PR.