Repository navigation
Conversation
An RPC stack that built its own engine left the skill watcher running after teardown. Stop that watcher before draining the owned stores, and continue the remaining cleanup if stopping it raises. Co-authored-by: Codex <noreply@openai.com>
gloryfromca
left a comment
There was a problem hiding this comment.
No blockers; this can merge as far as I am concerned.
Reviewed the refreshed github/main...HEAD diff and the surrounding RPC teardown, skill watcher lifecycle, other host cleanup paths, and relevant history. The owned/mounted boundary is preserved, repeated teardown is safe, and watcher-stop failures do not prevent store or transport cleanup. I also checked the repository rules and domain context, backward compatibility, callers, and that the tests add coverage rather than weakening existing assertions.
Verification: uv sync --locked --all-extras --dev succeeded; uv run pytest tests/test_rpc_bootstrap.py -q passed (24 passed in 6.01s). An initial run before syncing extras failed at fixture setup because raven_everos was absent; no tests executed in that attempt.
|
Windows compatibility review: no new issue found in the inspected scope. Reviewed head Native Windows / Python 3.13.12, in a detached temporary checkout with uv run pytest tests/test_rpc_bootstrap.py -n 0 -x --tb=short --basetemp "$reviewRunDir/pr910/tests"Result: 24 passed. No long-running server, large watched tree, or full repository suite was exercised. This scoped review does not establish full Windows compatibility. |
|
No blockers in the reviewed scope. Scope: I reviewed the full PR diff (2 changed files), including tests and documentation, and traced affected callers and contracts at Checked owned versus mounted loops, producer-before-drain shutdown order, repeated teardown, and failure continuation. A mounted loop returns before the new watcher cleanup; an owned watcher is stopped without preventing later store or transport cleanup if it raises. Verification (native Windows, Python 3.12, isolated source snapshots; local JUnit-output options omitted below):
The focused suites include the real SkillFileWatcher ownership/stop checks, repeated teardown, and cleanup after a watcher-stop exception. No new finding was identified. I also read the Python 3.13 Windows review. Its conclusions are consistent; the measurements here record a separate Python 3.12 run.
|
Summary
An RPC stack that built its own engine left the skill watcher running after teardown. Stop that watcher before draining the owned stores, and continue the remaining cleanup if stopping it raises.
A stack mounted on a host-owned engine leaves the host's watcher running. The regression uses a real local watcher and checks repeated teardown and failure isolation.
Type
Verification
Native Windows, Python 3.12. PYTHONUTF8=1; the existing environment was selected through UV_PROJECT_ENVIRONMENT, and PYTHONPATH pointed at this checkout.
Result: 3 passed in the targeted selection. The broader RPC/serve selection previously produced 136 passed, 2 failed and 26 skipped on Windows. Both failures reproduced on the unmodified base: owner-only POSIX mode bits and the supervisor SIGTERM cleanup test. The relevant-tests box is left unchecked because that broader selection is not all green.
Whole-branch gates:
All listed gates passed. The whole-branch review covered callers, ownership, guard boundaries, failure paths, regression strength, architecture and compatibility. No screenshot change applies; directly affected code documentation is updated where needed. The full repository suite and Linux/macOS execution were not run locally; the local Docker Linux engine was unavailable.
Risk
Cleanup applies only to the engine owned by this RPC stack. Mounted stacks retain host ownership. Stop failures are logged without preventing the remaining resources from closing. Revert the squash commit to roll back.
Related Issues
#490