agent-ops
OPS-106
tick.py execute() is sequential: one slow agent blinds the whole roster and delays post-nudge escalation (2.5min measured)
Done high
mcmonitor-context-cc
tick.py execute() runs agents strictly sequentially; each tmux keystroke+settle path can block up to 600s. Measured 2026-08-01: decision at 10:57:25 (skip_idle, idle not sustained) -> exec_begin 11:00:26 for coder-venus-cc = 2.5min decision-to-exec lag. Consequences: (1) the whole roster is blind while one agent is being actuated, so a fast-growing agent can cross the auto-compact ceiling unmeasured; (2) the new post-nudge escalation tier is delayed by the same amount, which is exactly the window it was built to close. Fix direction: bound per-agent execute time and/or actuate concurrently; measure before choosing. Owner lane: venus actuator. mem:project_monitor_context_venus_actuator.md
Questions
No questions.
Activity
-
Fixed by the systemd-run detach; measured, not assumed. execute() no longer runs inline in the tick. dispatch() launches a transient per-agent unit (ctxact-<agent>.service, tick.py --execute-one), so a 600s settle wait no longer blocks the roster scan. Measured on venus, 2026-08-05 onward: - dispatch -> exec_begin: n=172, avg 0.09s, max 0.14s. The ticket's measured figure was 2.5min (150s) decision-to-exec on 2026-08-01. - full tick run_begin -> run_end: n=10878, avg 0.73s, max 152.5s, only 4 runs over 30s. The 152.5s tail is not this defect. Every tick over 20s falls in 2026-08-09 05:57-06:45: 05:57:45 (36.0s), 06:17:17 (58.7s), 06:18:30 (25.1s), 06:27:06 (152.5s), 06:45:04 (112.1s). That is the venus OOM cascade window - context-venus-tick.service was OOM-killed at 06:22:37, 06:33:37 and 06:44:50 (previous boot) and Elazar rebooted at 06:47. External memory pressure, reported by coder-mars-cc, not sequential execution. Since the reboot the tick peaks at ~22M per run. Coverage statement: this is venus only, 2026-08-05 onward, and it measures dispatch latency and tick duration. It does not measure whether a concurrently-actuated agent is correctly handled under contention - the per-agent lock (execute_one_locked) is asserted by construction here, not exercised by this data.
bug
2w ago by wi-cli-venus
1w ago
2026-08-09 07:18