Repository navigation
fix(workers): keep pi-family workers active when agent_end will continue - #11
Closed
guilhermexp wants to merge 5 commits into
Closed
guilhermexp wants to merge 5 commits into
guilhermexp wants to merge 5 commits into
Conversation
agent_end com willContinue=true é continuação já agendada, não settle terminal; o emitter da família pi conserva Start até o fim real.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ck fails at its first step, `cargo fmt --all -- --check`, on two files: `crates/ui/src/shell.rs:10371` (the `compaction_marker` test asserts) and `third_party/zui/crates/gpui/src/elements/img.rs:354`. This branch doesn't change either file. `git diff 78c39bf..HEAD` on both is empty, and running `cargo fmt --all -- --check` locally flags the same two spots. So the formatting drift was already on the base branch (`main` at 78c39bf) and isn't caused by the worker-lifecycle fix. The user intent says the only new content in this PR is the pi-family `willContinue` fix and its OpenSpec change. Reformatting unrelated UI and vendored zui code here would widen that scope. The right fix is a separate `cargo fmt --all` commit on `main`. Until that lands, this check will stay red on any PR based on the current `main`
…ck still fails at its first step, `cargo fmt --all -- --check`, on the same two files as last round: `crates/ui/src/shell.rs:10371` (the `compaction_marker` test asserts) and `third_party/zui/crates/gpui/src/elements/img.rs:354`. This branch doesn't touch either file. `git diff 78c39bf..HEAD` on both is empty. The PR only changes the pi-family lifecycle files (`lifecycle-extension.js`, `adapter/setup.rs`), the fix-worker-turn-lifecycle OpenSpec change, `crates/workers-unpeel/AGENTS.md`, `third_party/unpeel-upstream.toml` and some graft cache files. So the formatting drift was already on the base branch (`main` at 78c39bf). Reformatting unrelated UI code and vendored zui code here would go beyond the stated intent, which is that the only new content is the `willContinue` fix. The fix is a separate `cargo fmt --all` commit on `main`. Until that lands, this check will stay red on every PR based on the current `main`
…ck fails at its first step, `cargo fmt --all -- --check`. It flags only two files: `crates/ui/src/shell.rs:10371` (the `compaction_marker` test asserts) and `third_party/zui/crates/gpui/src/elements/img.rs:354`. I re-checked with `git diff 78c39bf..HEAD`, and this branch changes neither file. It only touches the pi-family lifecycle files (`lifecycle-extension.js` and `adapter/setup.rs`), the fix-worker-turn-lifecycle OpenSpec artifacts, `crates/workers-unpeel/AGENTS.md`, `third_party/unpeel-upstream.toml` and some graft cache files. So the formatting drift was already on the base branch (`main` at 78c39bf), not introduced by the `willContinue` fix. Reformatting unrelated UI code and vendored zui code here would go beyond the stated intent, which is that the only new content is the pi-family lifecycle fix. The fix is a separate `cargo fmt --all` commit on `main`. After that lands and this branch is rebased, the check can go green. Until then it will fail on every PR based on the current `main`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
Revisar e publicar como PR para a main do fork (guilhermexp/comet) a branch repair/worker-activity-20260913. Objetivo: corrigir o lifecycle de workers pi-family — agent_end com willContinue=true é continuação já agendada pelo OMP, não settle terminal. O lifecycle-extension.js anunciava Stop incondicionalmente, o que fazia o painel piscar ocioso no meio do turno e, pior, alimentava o relógio de ociosidade da hibernação (crates/workers-unpeel/src/activity_bridge.rs usa o último evento de hook durável como sinal de atividade), tornando o worker candidato a hibernação no meio de um turno. O fix faz o emitter da família pi conservar Start até o fim real: pula o Stop quando event.willContinue === true, com testes no adapter setup.rs e artefatos OpenSpec do change fix-worker-turn-lifecycle (proposal/design/specs/tasks). A branch também contém um merge commit que apenas traz 24e08d1, já presente em main — o conteúdo efetivo novo é só esse fix. Trabalho 100% do fork: third_party/unpeel e crates/workers-unpeel não existem no upstream. Após o PR ser criado, a branch local e o worktree serão deletados; a remota fica até o merge.
What Changed
lifecycle-extension.js(the vendored pi-family lifecycle extension) no longer sends aStophook whenagent_endarrives withwillContinue === true, which means OMP has already scheduled a continuation or retry.Stopis still sent on a terminal end (willContinue === false) and on older events that don't have the flag. As a result, the panel no longer shows the worker as idle partway through a turn, and the hibernation idle clock no longer counts that falseStopas activity.adapter/setup.rsnow collects every hook payload the extension emits.lifecycle_extension_reports_provider_session_identitychecks two cases. In the first, a continuation followed by a terminal end sends onlyStartand thenStop. In the second, a legacyagent_endwithout the flag still sendsStop. Both cases also check that the session id and transcript path are kept.fix-worker-turn-lifecycle(proposal, design, spec delta, tasks). Updatescrates/workers-unpeel/AGENTS.mdwith thewillContinuerule and the test command, and adds a note tothird_party/unpeel-upstream.tomlwith the newvendored_tree. The branch also commits files undergraft/.cache/: four session JSON files andtelemetry-repo-id.json.🤖 Generated with Claude Code
Risk Assessment
✅ Low: The change is a one-guard fix in the pi-family lifecycle emitter. It skips Stop only when
willContinueis strictly true, so the legacy path without the flag and terminal ends still emit Stop. A behavioral Bun harness test covers the continuation, terminal and legacy cases, and thevendored_treehash matches the committedthird_party/unpeeltree.Testing
I ran the targeted adapter test in unpeel-core, which passed, but that is a unit test, so its scenario is marked untested for the live contract. I then drove the real OMP 18.2.5 binary with the shipped lifecycle extension against a fake provider that drops the connection mid-stream, which makes OMP send
agent_endwithwillContinue: true. The pre-fix extension sent a Stop in the middle of the turn (the bug, reproduced). The fixed extension sends only Start until the real end of the turn, including across chained retries, and still sends exactly one Stop on success, on retry-budget exhaustion and on plain turns. The effect on the comet hibernation bridge is also untested, because that needs the full GUI app. This change has no visual surface; the evidence is the captured hook transcripts. I removed the cargo target dir from the worktree.Evidence: Live OMP before/after hook transcripts summary
Evidence: Pre-fix hooks on OMP retry (bug reproduced)
OMP: agent_end{willContinue:true} → hooks Start, Stop, Start, StopEvidence: Post-fix hooks on OMP retry
OMP: agent_end{willContinue:true} → hooks Start, Start, StopEvidence: Post-fix hooks when retry budget runs out
Evidence: Fake provider used to force OMP continuations
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
✅ **Review** - passed
✅ No issues found.
✅ **Test** - passed
✅ No issues found.
cd third_party/unpeel/crates && cargo test -p unpeel-core lifecycle_extension(6 passed: the setup.rs harness tests for pi/omp/prime-agent plus the --extension wiring tests)Filled in lifecycle-extension.js from base 78c39bfe and target fda33e5c, the same way render_lifecycle_extension does, pointing it at a capturing notify scriptRan realomp -p --model fakeprov/fake-model -e probe.js -e ext-{before,after}.jsin an isolated HOME, against a local fake provider (fake_provider.py) with these modes: 503, empty stop, error chunk, mid-stream drop x1/x2/always, and two separate promptsThe probe extension logged OMP's raw agent_start/agent_end events (including willContinue) next to the hooks the lifecycle extension sent✅ **Document** - passed
✅ No issues found.
third_party/unpeel/runtimes/_shared/pi-family/adapter/setup.rs:136- Standalone rustfmt wants to collapse the newrun_lifecycle_harness(r#"..."#)call onto one line (and a pre-existingwrite_executable_scriptcall at line 43). The file is outside thecargo fmt --allworkspace, and the vendored code was never formatted. Reformatting it would also change thevendored_treehash recorded in third_party/unpeel-upstream.toml, so it was left unchanged.✅ **Push** - passed
✅ No issues found.