fix(runtime): probe Windows Effect process without signals - #3423
Merged
Conversation
huangruiteng
force-pushed
the
codex/fix-windows-effect-runtime-lifecycle
branch
from
August 21, 2026 14:05
01f0b1d to
1f3252b
Compare
Signed-off-by: huangruiteng <huangrt01@163.com>
huangruiteng
force-pushed
the
codex/fix-windows-effect-runtime-lifecycle
branch
from
August 21, 2026 14:10
1f3252b to
8a51c51
Compare
Owner
Author
|
Maintainer self-review: ready to merge once the final full-suite job is green. Product and architecture judgment
Validation evidence
This coverage is sufficient because the semantic boundary is narrow, the two failure modes have dedicated regression assertions, and the affected OS path has passed the repository's native Windows end-to-end lifecycle workflow. I found no remaining blocker in the diff. |
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.
Summary
kill(pid, 0)liveness probe on Windows with a read-only process-handle waitRoot cause
PR #3416 added a shared managed TypeScript Effect runtime and read its persisted PID before every request. On POSIX,
os.kill(pid, 0)is a side-effect-free existence probe. On Windows, Python documentsos.killas a signal/termination API; signal value0maps to the console Ctrl-C event rather than POSIX probe semantics. The metadata read therefore interrupted the test runner while it was blocked insocket.recv, producing 19 passing tests followed byKeyboardInterrupt.The Windows branch now opens the process with
SYNCHRONIZE, checks it usingWaitForSingleObject(..., 0), and closes the handle.WAIT_TIMEOUTmeans the process remains live. Access-denied processes are treated as live because existence was established but query authority was unavailable.The first native rerun then exposed the adjacent lifecycle bug: 37 tests passed, but
test_windows_installer_promotes_release_and_runs_doctortimed out after 180 seconds. The installeddoctor --deepprocess started the runtime withclose_fds=False, so the long-lived Node child inherited the installer's captured stdout/stderr pipe handles andsubprocess.communicate()could not observe EOF. Runtime launch now always closes unrelated descriptors; its own standard streams remain explicitly connected toDEVNULL.Validation
35 passed, 6 skipped11 passednpm run typecheck:control-plane: passednpm run test:control-plane: 18 passedgit diff --check: passedcqr_8de9da1b2b723f2a082d, exact-scope valid on the latestmainwindows-latestPR checkRisk boundary
This changes Windows process liveness observation and prevents unrelated handle inheritance at runtime launch. It does not change Effect Program interpretation, effect identity, retry safety, journal persistence, adapter behavior, installation semantics, or runtime shutdown authority.