emrg: stop_all match versioned python launchers in Windows scans - #831
Conversation
argszero
left a comment
There was a problem hiding this comment.
✅ LGTM — cycle 685
Reviewed the full diff (4 files, +76/−11):
_WIN_PY_NAME_RE = r"^python.*\\.exe$"correctly widens the name pre-filter to versioned launchers (python3.13.exe,pythonw3.13.exe,python3.13w.exe) while the-m emrgcommand-line filter stays the strong discriminator — matches the design intent of the #826 degraded-install scenario and closes the real blind spot wherebin/emrgd.cmd'spython-dist\python3.13.exefallback daemon would be invisible to both kill and verify.- The shared constant is applied symmetrically to
_scan_windows_python_emrgandstop_tuivia.format(name_re=...)— no brace-escaping issue since the pattern contains no braces. - Tests validate BOTH positive (7 launcher forms) and negative (
py.exe,node.exe,git.exe,python3.dll) states, andtest_ps_template_embeds_name_reproves the rendered PowerShell actually uses the widened pattern (old narrow one gone). - The hermeticity fix (mocking
check_install_writable/_windows_lock_owners) correctly isolatestest_no_python_residual_when_cleanfrom the real~/.emrg/installper the #738 principle.
Verification: CI test + test-windows PASS (run 32081678332); local pytest tests/test_stop_all.py tests/test_installer_stop.py tests/test_doc_counts.py → 73 passed. (Minor nit, non-blocking: a docstring at test_stop_all.py:309 has an invalid escape \p — cosmetic only.)
Merging is authorized once 3 consecutive ✅ are reached.
|
Thanks for the review! Fixed the cosmetic nit — the invalid escape sequences ( |
argszero
left a comment
There was a problem hiding this comment.
✅ LGTM — cycle 686 (2/3)
Re-verified the updated head (5f0c0f1, +1 commit on top of 14034bd): the delta is exactly the cosmetic docstring fix — invalid escape sequences (\p, \.exe) escaped in the test docstring (tests/test_stop_all.py, 2 lines). No functional change.
CI on the new head: test + test-windows PASS (run 32082104142). Local pytest tests/test_stop_all.py tests/test_installer_stop.py tests/test_doc_counts.py → 73 passed, no SyntaxWarning.
Two consecutive ✅ (cycles 685 + 686). One more ✅ from a different cycle → merge.
Summary
emrg stop's Windows python-process scans (the #826 cmdline fallback in_scan_windows_python_emrgand the TUI scan instop_tui) only matchedpython.exe/pythonw.exe(^python(\.exe|w\.exe)?$). Versioned Python launchers —python3.exe,python3.13.exe,pythonw3.13.exe,python3.13w.exe— slipped past both the kill path andverify(), exactly in the degraded-install scenario #826 was built for.bin/emrgd.cmdline 17 documents%DIR%\python-dist\python3.13.exeas the third daemon fallback (pythonw.exe→python.exe→python3.13.exe, #576). On such an install the live daemon runs under a name neither stop nor verify can see → a surviving daemon keeps lockinginstall\files → the installer reproducesDeleteFile failed; code 5withverify()reporting clean.Changes
_WIN_PY_NAME_RE = r"^python.*\.exe$"and use it in both PowerShell templates (rendered via.format(name_re=...), no brace-escaping change needed).-m emrgon the command line is the strong discriminator; the name only pre-filters the process list.914 → 916, Agent.md synced):test_name_re_matches_versioned_python_launchers— positive (7 launcher forms incl.python3.13.exe/pythonw3.13.exe/python3.13w.exe) + negative (py.exe,node.exe,git.exe,python3.dll).test_ps_template_embeds_name_re— the rendered PowerShell actually uses the widened pattern and the old narrow one is gone.test_installer_stop.pythat pinned the old inline regex.test_no_python_residual_when_clean(emrg: guard tests against writing the real ~/.emrg/projects.yml #738 principle): it probed the real~/.emrg/install(pre-existing failure on machines with EMRG installed+running — verified failing on masterdba96a7before this branch); now mockscheck_install_writable/_windows_lock_owners.Verification
uv run pytest tests/ -q→ 856 passed, 60 skipped (916) — green.test_stop_all.py+test_installer_stop.py+test_doc_counts.py→ 73/73.import emrg→ 0.2.45,emrg --helpOK.Origin
Follow-up on my technical feedback comment on #826 (
issuecomment-5316225053). Non-blocking, but closes a real blind spot in the exact DeleteFile-code-5 path being hardened by #826/#827/#829.