mirror of
https://github.com/thedotmack/claude-mem.git
synced 2026-09-20 04:23:02 +08:00
weiconghe
32a3fd9b07
* fix(windows): make the ghost gate's fixture handshake independent of stdout buffering
The revision landed as 155fefce (#3989) fixed the unbounded port probe, but the
gate it was meant to unblock still fails on CI. Every failing run has the same
shape: no stage output, exactly `2 expect() calls`, and the fixture's `ready`
line only visible once the fixture is killed at the 600s cap — while the
fixture's chroma chain is already alive 3s in. The handshake read a redirected
stdout, and a single small line written by a process that then idles can sit
unflushed in that buffer indefinitely.
The fixture now appends every event to an events file (a syscall per call —
nothing left to flush) and keeps the stdout copy for human debugging, plus
emits progress stages with elapsed times. The test reads readiness from the
file, prints `waiting for fixture ready: elapsed=… lastStage=…` every 15s so
the timeline survives even a bun-timeout kill, gives up at 240s (below bun's
cap) with the full events/stdout/stderr dump, and reaps an in-flight
ensureWorkerStarted() during teardown instead of leaving it running past
cleanup.
Locally the gate passes in 41.9s with the stage timeline visible: fixture ready
after 6.1s, ghost confirmed, ensureWorkerStarted 'ready' after 27.4s.
* test(windows): sweep stragglers an abandoned launcher leaves behind
The deadline race cannot cancel ensureWorkerStarted(), so teardown waits for it
— but that wait is time-boxed, and a launcher still mid-flight can spawn its
worker or reclaim the chain AFTER the kills. Fault-injection check (deadline
temporarily at 1s, which abandons the launcher mid-flight): teardown used to
leave a ghost listener on the port and a live isolated chroma chain behind
(ghost owner dead + 3 surviving sidecar processes). Teardown now repeats
"reap the pid-file worker, free the port via the production reclaim" in bounded
rounds until the port is quiet; the same injection now leaves zero listeners
and zero surviving isolated processes, and the green path still passes in 40s.
* test(windows): give the ghost gate's event channel a real contract
The events file this handshake reads was never written. `process.env.X = ...`
does not survive child_process in bun (children get the environment the
runner started with), so the fixture only ever emitted to stdout — and the
reader's stdout fallback hid that: every local run "passed" on the fallback
while CI, where redirected stdout is buffered, kept hanging. Probed:
A bash-set env -> child sees it
B process.env.X -> child does NOT see it
C { ...process.env } passed explicitly -> child sees it
- pass the events file path as argv[2] instead (no env anywhere in the
bun -> powershell -> Start-Process -> bun chain);
- stop reading stdout back: a broken channel must fail loudly, and stdout
cannot save a buffered CI run anyway;
- events carry the port, so a listener is sweepable without `ready`;
- record the detached fixture's pid the moment Start-Process returns and
tree-kill from it when readiness never arrives — previously that fixture
had no teardown handle at all and outlived the run;
- document why the readiness deadline stays far below the 600s test cap.
* test(windows): unbind the ghost gate from the runtime it runs on
Three stalls, one commit, because they only separate under the runtime CI
uses (bun 1.4.x; the local default here is 1.3.6).
- The launch call never returned. execFileSync(powershell ...) with a stdout
pipe waits for EOF, and the DETACHED fixture inherits that pipe, so it never
closes while the fixture lives: the call returns only when something kills
the fixture — which is why every red CI run showed the fixture alive for the
full 600s and the ready line "after 0ms" (that is the moment the stall ended,
not a handshake problem). The pid now travels through a file and the call
runs with stdio 'ignore' — the same shape production's spawnDaemon() uses on
Windows. Reproduced on bun 1.4.0 locally: the gate now proceeds.
- The scenario is runtime-dependent. bun >= 1.4 no longer inherits the
listening socket into spawned children: identical code on one machine —
1.3.6 leaves the port LISTENING under the dead worker, 1.4.0 releases it with
the worker (the sidecar chain still survives; it just no longer holds the
socket). Where no ghost forms and the chain was verified present, the gate
now reports that and skips the recovery assertions instead of failing on the
runtime's behaviour.
- Every child-process call in the gate is bounded now (taskkill had no
timeout), and the kill-to-ghost window logs elapsed times, so a future stall
names the step it is stuck in.