The clean-path soak found no leak on windows-latest — because orderly close()
reaps every host. That never exercises the freeze hypothesis (T-424), which is
the parent dying WITHOUT teardown while a child is live.
This probe does. conpty_orphan_probe.dart starts N real WindowsPty sessions on
long-lived children and blocks WITHOUT ever calling close(); soak-conpty-kill.ps1
force-kills only the dart.exe parent (taskkill /F, no /T) once the hosts are up
and counts the conhost/OpenConsole/cmd processes that SURVIVE. Absent a
kill-on-close Job Object, abrupt parent death should orphan them — a survivor
count that climbs across cycles is the leak signature. The same probe will prove
the T-424 fix: with the job, survivors should drop to ~0.
Wired as a second job in windows-soak.yml (workflow_dispatch + when the kit
changes). Diagnostic only, never a gate, always exits 0; publishes the verdict
to the job summary and uploads the CSV. Not part of the regular test suite.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The freeze diagnosis (T-424) was going to need a dedicated Windows VM to soak-
test. It doesn't: GitHub's windows-latest already runs our ConPTY suite green,
and tools/windows-verify/soak-conpty.ps1 detects the leak by counting the
conhost/OpenConsole hosts that survive each run — it never tries to crash the
box, so a throwaway runner works. The repeated runs happen inside one job, so
the orphan count can climb there even though the runner is discarded after.
New windows-soak.yml: workflow_dispatch + triggers when the soak kit changes.
Diagnostic only (always exits 0); publishes the verdict to the job summary and
uploads the CSV. This removes the GCP/VM requirement from the human entirely.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jpmschweitzerandClaude Opus 4.8