code-yeongyu / code-yeongyu/senpi

ci(windows): remaining RPC named-pipes job flake variants (host-ensure concurrent-start SIGTERM, lifecycle hostAlive probe)

Open
#1,290 13 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
429
Forks
98
Avg merge
5h 3m
Merged PRs (30d)
526

Description

## Summary

The `RPC named pipes (Windows)` CI job (runs `test/rpc-host-ensure.test.ts` and `test/rpc-host-lifecycle.test.ts` on windows-latest) fails intermittently with several independent variants. Two were fixed at the root today; two remain and are tracked here so they are not mistaken for regressions in unrelated PRs.

## Fixed at the root (2026-09-02)

- #1288 - `serializes concurrent starts for one socket across agent directories` -> `Error: database is locked`: ensure-lock wait (10 s) shorter than the holder's critical section.
- #1284 - `starts a fresh host transparently on the next ensure after an idle exit` -> `Stop-Process` on an already idle-exited pid / `ENOENT host.pid`: teardown and pidfile read raced the 600 ms idle exit.

## Still open

1. `rpc-host-ensure.test.ts > serializes concurrent starts for one socket across agent directories` -> `Error: RPC socket host exited with code null (SIGTERM) before answering get_protocol_info`, followed by `ENOTEMPTY ... rmdir senpi-host-ensure-cross-agent-race-*` in cleanup. Seen: run 33602751743 attempt 1 (PR #1277), run 33615244048 attempt 2 job 100202119649 (PR #1277 at 44c7414bb, which does not touch host-ensure). The second caller ends up spawning (its existing-host probe did not reuse the first caller's fixture host) and its spawned host is SIGTERM'd before readiness - candidate causes: the 10 s existing-host probe timing out on the runner and `stopManagedHost` terminating the live fixture, or pidfile identity confusion between the two agent dirs.
2. `rpc-host-lifecycle.test.ts > does not exit while a turn is active even with no connections; exits after the turn settles` -> `expect(await hostAlive(entry.pidFile)).toBe(true)` false at line 201. Seen: run 33602751743 attempt 2 job 100164143208 and run 33615244048 attempt 1 job 100199445430 (both PR #1277; the same file passes on macOS/Linux with the same tree). `hostAlive` goes through the 1 s PowerShell CIM identity probe (`readProcessStartTime`) with no retry, so a slow probe reads as "host gone"; production callers got retry in 1640d9b67, this test helper did not.

## Suggested next steps

- Variant 2: give the test's `hostAlive` the same bounded retry the production probe has (or reuse `waitForStartTime`), and capture supervisor stderr on failure to distinguish a real exit from a probe timeout.
- Variant 1: log which branch `ensureHostLocked` took for the second caller (reuse / stop+spawn) and the probe timing; on Windows consider lengthening `EXISTING_HOST_PROBE_TIMEOUT_MS` or serializing the fixture's readiness with the lock release.

Contributor guide

Open the contributing guide

Research direction

Start with test/rpc-host-ensure.test.ts and test/rpc-host-lifecycle.test.ts on windows-latest, then trace ensureHostLocked, stopManagedHost, hostAlive, readProcessStartTime, and waitForStartTime. Use the cited CI runs and supervisor stderr to distinguish probe failures, host lifecycle races, and pidfile identity issues. Done means both named tests are reliable on Windows and the failure diagnostics identify any remaining variant.

Written by the indexing model from the issue text.

Assessment

Tech stack
powershell, typescript
Domain
ci-cd, operating-systems, testing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.