fix(windows): one scheduler-wrapper killer, scoped to one installation - #1945
fix(windows): one scheduler-wrapper killer, scoped to one installation#1945lidge-jun wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (2)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
|
✅ Deterministic PR hygiene checks passed. |
src/service.ts and src/update/job.ts each carried a copy of the same teardown logic, and the copies drifted in both directions. service.ts matched canonical full paths as complete command-line tokens; update/job.ts matched the bare filenames with -like '*name*'. Meanwhile update/job.ts had received the #1589 argv cleanup that service.ts had not. The bare-filename matcher is the defect. Two OpenCodex homes under one Windows account means a dashboard update for home A can force-terminate home B's scheduler wrapper, and any unrelated process whose command line contains either filename matches as well. Extracted the service.ts implementation, which was the correct one, into src/lib/windows-service-wrappers.ts and pointed both callers at it. The updater now passes its own config dir instead of bare names. windowsWrapperKillScript is exported because the matching rule is the entire point of the module and the spawn reports nothing: the script it builds is the only observable surface, which is the same source-level convention windows-deploy-close-regressions.test.ts already uses. New tests/windows-service-wrappers.test.ts pins that another home's path is not among the patterns, that matching is token-bounded rather than substring, that the caller excludes itself, and that neither file keeps a private matcher. The last assertion was driven red first: both files failed it before the extraction. windows-deploy-close-regressions.test.ts asserted "$_.ProcessId -eq $PID" against update/job.ts. That string moved, so the assertion follows it to the shared module rather than being dropped. Verification: bun test over service, windows-deploy-close-regressions, windows-popup-fix and the new file (143 pass), bun run typecheck clean.
a8cef7d to
a3169db
Compare
Summary
src/service.tsandsrc/update/job.tseach carried a copy of the same teardown logic, and the copies drifted in both directions.service.tsmatched canonical full paths as complete command-line tokens;update/job.tsmatched the bare filenames with-like '*name*'. Meanwhileupdate/job.tshad received the [Bug] Windows PowerShell-WindowStyle Hiddencauses EACLIDENTITY under Bun #1589 argv cleanup thatservice.tshad not (fixed in the parent PR).service.tsimplementation, which was the correct one, intosrc/lib/windows-service-wrappers.tsand pointed both callers at it. The updater now passes its own config dir instead of bare names.windowsWrapperKillScriptis exported because the matching rule is the entire point of the module and the spawn reports nothing: the script it builds is the only observable surface, which is the same source-level conventionwindows-deploy-close-regressions.test.tsalready uses.windows-deploy-close-regressions.test.ts,cli-ready.test.ts). They follow the invariant to the shared module rather than being dropped.Second of a stacked chain implementing
devlog/_plan/260817_windows_stability_program/(phase020). Targets #1944; retarget todevonce that lands.Verification
bun test tests/windows-service-wrappers.test.ts— 5 pass (new file)bun test tests/service.test.ts tests/windows-deploy-close-regressions.test.ts tests/windows-popup-fix.test.ts tests/windows-service-wrappers.test.ts— 143 passbun test tests/cli-ready.test.ts— 57 passbun run typecheck— cleanChecklist