배경
#762 / #766 이 packages/orchestrator 쪽 하드코딩 pid 의존을 닫았습니다. 같은 부류가 packages/cli 에 1건 남아 있습니다 — #766 리뷰 중 재현했습니다.
packages/cli/src/commands/lifecycle.test.ts:585 의 it("reports recoverable runs without invoking recovery in dry-run mode") 는 stale run 을 processId: 999_999 로 저장하고, recover --dry-run 은 실제 프로세스 테이블을 조회합니다. 해당 pid 가 살아 있는 머신에서는 그 run 이 recoverable 로 잡히지 않아 실패합니다. Linux 기본 pid_max 는 4194304 이므로 999999 는 충분히 실재할 수 있는 pid 입니다.
재현
vitest.setup 에서 process.kill(pid, 0) 을 cli 테스트의 pid 리터럴 집합(1, 2, 111, 123, 222, 456, 1234, 2468, 4321, 5678, 999999, 999999999)에 대해 성공시키면 재현됩니다. 서비스/CLI 가 프로세스 그룹을 볼 수 있으므로 음수 pid 도 함께 가로채야 합니다.
FAIL src/commands/lifecycle.test.ts > lifecycle command integration > reports recoverable runs without invoking recovery in dry-run mode
AssertionError: expected false to be true // Object.is equality
❯ src/commands/lifecycle.test.ts:611:7
pnpm --filter @gh-symphony/cli test 기준 1 failed / 590 passed. 나머지 41개 파일은 같은 조건에서 전부 통과하므로 노출면은 이 1건입니다.
pid: 1, pid: 2 를 쓰는 테스트도 있으나(리터럴 기준) 시뮬레이션에서 깨지지 않았습니다 — 실제 liveness 조회로 흘러가지 않는 것으로 보입니다. 다만 1·2 는 어느 Linux 머신에서나 살아 있는 pid 이므로, 수정하는 김에 같이 점검해두면 좋겠습니다.
수정 방향
#766 이 orchestrator 에서 쓴 방식 그대로가 맞습니다 — 테스트에서 liveness 프로브를 주입 가능하게 하고 false 를 주입한 뒤, 그 pid 가 실제로 평가됐음을 단언해 seam 을 지킵니다. cli 쪽 recover 경로에 동등한 주입 지점이 없다면 먼저 뚫어야 합니다(packages/cli/src/daemon-liveness.ts, packages/cli/src/commands/recover.ts 확인 필요).
완료 기준
- 위 시뮬레이션 조건에서
pnpm --filter @gh-symphony/cli test 가 결정적으로 통과
pnpm --filter @gh-symphony/cli test 10회 연속 통과- changeset 불필요(테스트만)
참고
#766 리뷰에서 별도 이슈로 분리하기로 한 항목입니다. #766 자체는 범위대로 완료되어 Approve 했습니다.
배경
#762 / #766 이
packages/orchestrator쪽 하드코딩 pid 의존을 닫았습니다. 같은 부류가packages/cli에 1건 남아 있습니다 — #766 리뷰 중 재현했습니다.packages/cli/src/commands/lifecycle.test.ts:585의it("reports recoverable runs without invoking recovery in dry-run mode")는 stale run 을processId: 999_999로 저장하고,recover --dry-run은 실제 프로세스 테이블을 조회합니다. 해당 pid 가 살아 있는 머신에서는 그 run 이 recoverable 로 잡히지 않아 실패합니다. Linux 기본pid_max는 4194304 이므로 999999 는 충분히 실재할 수 있는 pid 입니다.재현
vitest.setup에서process.kill(pid, 0)을 cli 테스트의 pid 리터럴 집합(1, 2, 111, 123, 222, 456, 1234, 2468, 4321, 5678, 999999, 999999999)에 대해 성공시키면 재현됩니다. 서비스/CLI 가 프로세스 그룹을 볼 수 있으므로 음수 pid 도 함께 가로채야 합니다.pnpm --filter @gh-symphony/cli test기준 1 failed / 590 passed. 나머지 41개 파일은 같은 조건에서 전부 통과하므로 노출면은 이 1건입니다.pid: 1,pid: 2를 쓰는 테스트도 있으나(리터럴 기준) 시뮬레이션에서 깨지지 않았습니다 — 실제 liveness 조회로 흘러가지 않는 것으로 보입니다. 다만 1·2 는 어느 Linux 머신에서나 살아 있는 pid 이므로, 수정하는 김에 같이 점검해두면 좋겠습니다.수정 방향
#766 이 orchestrator 에서 쓴 방식 그대로가 맞습니다 — 테스트에서 liveness 프로브를 주입 가능하게 하고
false를 주입한 뒤, 그 pid 가 실제로 평가됐음을 단언해 seam 을 지킵니다. cli 쪽 recover 경로에 동등한 주입 지점이 없다면 먼저 뚫어야 합니다(packages/cli/src/daemon-liveness.ts,packages/cli/src/commands/recover.ts확인 필요).완료 기준
pnpm --filter @gh-symphony/cli test가 결정적으로 통과pnpm --filter @gh-symphony/cli test10회 연속 통과참고
pnpm test전체를 게이트로 쓰는 로컬 에이전트 파이프라인은 무관한 이슈에서 반복 차단될 수 있습니다.#766 리뷰에서 별도 이슈로 분리하기로 한 항목입니다. #766 자체는 범위대로 완료되어 Approve 했습니다.