fix(#266 PR-2): CI-robust reset_server — explicit PID kill, drop pkill/dev-tcp

[vansin]

Author

Agent: 通信测试马 (claude-code-cli)
Dispatch: 通信龙 task b4c67c72 ("PR-2 你直接开干 ✅, 显式 SERVER_PID + kill -KILL + wait, 让 #273 在 CI 真生效")
Refs: #266 (audit), #273 (original reset_server), #279 (Bucket A follow-up), #277 (A1 helper refactor)

Summary

#273's reset_server works locally (V3 Networks 19/3) but silently regresses in CI (V3 Networks "0 ran"). This PR rewrites the helper to be deterministic regardless of environment.

	Base E2E	V3 Auth	V3 Networks	Config Priority	TOTAL
CI run 28308477515 (912d642, pre-PR-2)	90/45	25/0	⚠️ 0 ran	⚠️ 0 ran	115/47
Local same commit (pre-PR-2)	90/45	25/0	19/3	⚠️ 0 ran	134/49
Local with PR-2	90/45	25/0	20/2	⚠️ 0 ran	135/48

The only delta CI vs local was V3 Networks visibility — exactly where reset_server was failing silently.

Root cause

Original reset_server used:

• pkill -f 'bun.*src/index.ts' — pkill -f can miss the bun process when argv exposure differs (e.g. invoked via a wrapper that obscures src/index.ts in /proc/<pid>/cmdline)
• (exec 3<>/dev/tcp/127.0.0.1/9200) — bash-only pseudo-file that may behave differently under GHA's runner Docker process model / cgroup setup

Either failure mode leaves the previous bun bound to :9200 when V3 Networks fires its own bun run src/index.ts, which gets EADDRINUSE in the background. The suite proceeds against the polluted shared server and exits early without reaching its Results: … line → test-all.sh's regex finds nothing → "0 ran" warning.

Fix

SERVER_PID=""
reset_server() {
  if [ -n "$SERVER_PID" ]; then
    kill -KILL "$SERVER_PID" 2>/dev/null || true
    wait "$SERVER_PID" 2>/dev/null || true
  fi
  sleep 0.5                                    # kernel socket release
  rm -rf /root/.commhub /root/.anet 2>/dev/null || true
  (cd /app/server && exec bun run src/index.ts) &>/dev/null &
  SERVER_PID=$!
  for _ in $(seq 1 30); do
    curl -sf http://127.0.0.1:9200/health > /dev/null && return 0
    sleep 0.5
  done
  echo "::warning::..." >&2
  return 1
}

• Explicit SERVER_PID capture → no pkill/grep
• kill -KILL + wait → synchronous reap of the prior server
• Subshell with (cd /app/server && exec bun ...) → cd doesn't leak into test-all.sh cwd; exec collapses the bash subshell so $! points at bun directly
• No /dev/tcp dependency

What this PR does NOT do

It does NOT make the workflow exit 0. Base E2E still reports 45 fails — pre-existing #266 Bucket A cascade (test-infra, not product bugs), tracked in #279. The job will still exit 1 until either:

• Bucket A clears (#266 follow-up: 2 more cascade layers + round-2 audit re-bucket (e2e-agent registration + grep "ok" false-positives) #279 Layer 2 + Layer 3 + audit re-bucket; multi-day effort)
• The workflow converts to report-only (echo verdict, always exit 0)

See docs/tests/report-266-docker-e2e-ci-vs-local-divergence.md for the full divergence analysis + Bucket A handling plan.

Test plan

• Local Docker rebuild + full test-all.sh → 135/48, V3 Networks 20/2
• Verify no pkill/grep/dev-tcp dependencies remain in reset_server
• Verify (cd ...) &; SERVER_PID=$! captures the bun PID (not the subshell PID — exec replaces the subshell)
• PR CI: Docker E2E run shows V3 Networks reporting 20/2 (or close), not "0 ran"
• After merge: main CI shows the same — first time CI matches local since fix(#266 Bucket B): reset server+DB between e2e suites — recover V3 Networks visibility (+19 tests) #273

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 304d5d5628

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Kill pre-existing server before trusting /health

When test-all.sh is rerun in an existing container or after an aborted run, SERVER_PID starts empty, so this block leaves any already-running bun run src/index.ts on :9200 alive. The new start then fails with EADDRINUSE, but the /health poll can still succeed against the stale process, causing the suites to run with old server/DB state—the pollution this reset is meant to prevent. Keep a fallback cleanup for untracked listeners before starting the captured PID server.

Useful? React with 👍 / 👎.