fix(test): isolate harness daemon runtimes - #1695
Conversation
Sorry, something went wrong.
Signed-off-by: astandrik <astandrik@yandex-team.ru>
|
Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144. What that means for this PR, concretely:
Things that will genuinely speed it up whenever review does happen:
If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. |
Sorry, something went wrong.
|
Thank you for preserving one clear invariant across the changed harnesses: no test process may inherit or affect the account daemon runtime. The shared helper plus a deterministic sentinel contract is a coherent slice even though it touches several scripts. Because this changes executable security and test harnesses, it will receive the full script and filesystem-boundary review once the PR leaves draft. The initial patch scan found no new external dependency, outbound network path, or product-code change. Please keep the broader smoke, soak, profiling, and benchmark audit in #1696 rather than expanding this PR. The queue is full, but the draft is labeled and routed as a high-priority isolation fix. |
Sorry, something went wrong.
What does this PR do?
Fixes #1691
Several test and security scripts inherited the caller's daemon runtime. That is unsafe for security-install.sh, which performs a real install inside a temporary home. Its activation step could stop the account daemon and disconnect MCP sessions used by an editor or coding agent.
This PR adds a shared test helper that creates a private runtime and cache before a harness invokes the product binary. It replaces inherited paths, uses protected temporary roots on each supported platform, and limits cleanup to the root created by that harness. The helper is wired into the eight security, watchdog, worker, and hook entry points covered by the issue.
The change does not touch product code, public APIs, Makefiles, workflows, dependencies, or configuration formats.
Failure before
The original reproduction started a sentinel MCP client in runtime A, then ran security-install.sh with the same inherited runtime. The install activation stopped daemon A, the frontend exited, and the daemon log recorded activation_shutdown.
Result after
The same reproduction now gives the install audit a separate runtime B. The sentinel answers a ping after the audit, daemon A keeps the same PID, and its logs contain no activation_shutdown. Runtime B is removed during cleanup.
Reproduction
The runnable fail-before reproduction is in #1691 under "Reproduction". It builds the product binary and starts a sentinel MCP client in a private runtime, so it does not touch the account daemon.
On this PR head, run the tracked pass-after contract:
It verifies that inherited runtime and cache paths are replaced, parallel runs receive different roots, cleanup leaves the caller's runtime untouched, creation failures stop the harness before the binary starts, and security-install.sh uses a private HOME, cache, and runtime.
The live-sentinel script from #1691 can also be run against this branch. The sentinel remains connected after the install audit, daemon A keeps the same PID, and runtime A records no activation_shutdown.
Validation
The full scripts/lint.sh run on the remote builder reaches the existing repository-wide clang-tidy baseline in unchanged C and header files. PR CI runs scripts/lint.sh --ci, which gates this test-only diff with cppcheck and clang-format.
Checklist