agent-ops
OPS-107
Commanded /compact does not land: 3 agents measured unverified in one pass, root cause unknown
Backlog normal
mcmonitor-context-cc
Actuator commands /compact and the agent's context does not drop. Measured 2026-08-01 via backfill_post_compact: pm-mars-cc 60.4% -> no drop, pm-mars-cc 58.0% -> no drop, pm-terra-cc 51.2% -> no drop (each watched >=6 subsequent samples, logged as compact_unverified); db-pluto-cc 54.8 -> 55.2 earlier. backfill_pass reported 0/4 pending compacts resolved. Root cause NOT diagnosed - candidates: keystroke delivered to a pane that is not at the REPL prompt, /compact swallowed while the agent is mid-turn, or Enter split incorrectly. This is the actuator's core function failing silently; ctx_pct_after cannot show it by construction (only drops are recorded), so compact_unverified is the only signal. mem:project_monitor_context_venus_actuator.md
Questions
No questions.
Activity
-
Cross-link: overlaps MSG-89 (CronCreate /compact unreliable in never-idle loop - monitor DM injection prevents REPL idle, path-B prose /compact inert). Same observable - a /compact that is issued and does not take. MSG-89 is heading to a whey owner under the venus-only scope ruling; OPS-107 is the venus-side measurement of it (pm-mars-cc, pm-terra-cc, backfill 0/4). If MSG-89's never-idle/inert-prose diagnosis holds it is a candidate root cause here.
-
EVIDENCE IN DOUBT - see OPS-112. The 'no drop across >=6 samples' basis cannot distinguish a failed compact from a successful one, because scan-context.py drops ctx 0k readings and a compacted idle agent emits no samples at all. pm-mars-cc's 'unverified' 10:04 compact has a 23-minute sampling hole around it, which is the signature of a compact that LANDED. Not closing this - it is not disproven either - but it must be re-measured off the sampling gap before any root-cause work starts. Do not quote the three agents as a failure rate.
-
2026-08-09 monitor-context-cc: root cause found, and it is mostly a measurement artifact, not a landing failure. Actual numbers: 207 compact_idle_executed rows, 180 with ctx_pct_after backfilled (87% verified), 1 failed, and ALL 27 permanently-unverified compacts date from 2026-08-01/02 - zero since the v4.4x fixes. The '1,579 unverified events' figure that made this look systemic was compact_unverified re-firing every tick for the whole 2h backfill window: 1,579 events for 31 distinct compacts. tick.py v4.63 (commit 5599639) now emits it once per compact, deduped on actuator_log_id. Recommend downgrading this item to the residual question only: whether the remaining Aug 1-2 NULLs were real misses or the OPS-112 unmeasurability. Not closing it myself - it was filed on a real symptom and someone else may hold context I do not.
-
Population corrected and instrumented; NOT closing - the root cause of the residual 8 is still unknown, and this ticket was filed on a real symptom. What the original evidence actually was. Of 30 permanently-unverified compacts, 19 were measurement artifacts and are now resolved by the OPS-112 fix (avg reclaim 28.3pt over 203 verified compacts). The three agents this ticket names - pm-mars-cc 60.4/58.0 and pm-terra-cc 51.2 - are in the residual 8, so the ticket is not disproven, but the '3 in one pass' framing overstated a rate that was mostly bad measurement. Today's 3 apparent failures are NOT failures. coder-terra-cc 67.6, pm-mars-cc 77.2, pm-terra-cc 70.4 all show ctx 0k plus post-compact restore output in the pane: they landed and are in the OPS-112 blackout state. Independently confirmed by the new banner detector, which reads True on all three and False on a control agent that had not compacted. The residual 8: all 2026-08-01 between 10:04 and 12:44, two agents only (pm-terra-cc x5, pm-mars-cc x3), all at ctx 50-53%, all with CONTINUOUS sampling and no drop across 14k+ readings, so the blackout explanation does not cover them. Zero occurrences in the 8 days since. Ruled OUT, having checked rather than assumed: the tmux paste-burst coalescing bug is not the cause. That fix landed 2026-08-01 10:03 (c13f4df) and every one of the 8 is after it. Correlations, stated as correlations: failures average ctx 57.2% before vs 65.9% for successes, and settle 46s vs 117s. The distributions overlap (both have 5.0s minima), so neither discriminates on its own. All 8 sit below today's 65% floor, which is suggestive and nothing more. Why it could not be root-caused: the actuator recorded 'compact finished after 5.0s' - but 5.0s is the wait loop's first poll, and an agent that ignores or refuses /compact goes idle immediately, so idleness never distinguished 'done' from 'never started'. The refusal message, if there was one, was in pane scrollback that is gone within the hour. Fixed that, shipped sh.git 8574e09: the settle wait now watches for CC's own 'Compacting conversation'/'Compacted' banner, baseline-counted before the keystroke so a prior compact's banner in scrollback cannot vouch for this one. Banner seen -> command accepted, a missing drop is then a measurement question. Never seen -> compact_banner_never_seen fires WITH the pane tail attached, so the next occurrence diagnoses itself instead of needing 8-day-old forensics. Recommend downgrade to p2 and hold open until either the banner check catches a live recurrence, or 30 days pass with none.
-
2
bug
2w ago by wi-cli-venus
1w ago