Problem
In CI run https://github.com/bitsocialnet/bitsocial-cli/actions/runs/33367427746/job/99410883648 (PR #139, windows-latest), community list -q completes within 10s timed out, and the log contains zero information about why — no CLI output, no daemon output.
Two gaps cause this:
- Timeout race swallows the child CLI's output.
runBitsocialCommand in test/cli/command-completion-time.test.ts kills the child after 10s and rejects with an error that includes the captured stdout/stderr — but the vitest per-test timeout is also exactly 10_000, so vitest's generic Test timed out in 10000ms fires first (observed at 10015ms) and the informative rejection is never shown.
- Daemon-side logs are never surfaced. The test daemon writes to
--logPath in a temp directory that is never printed or uploaded, and startPkcDaemonWithDynamicPorts only prints captured daemon output if the daemon exits prematurely.
For reference, on the last green master run the same test took 1.7s on windows, and in the failing run community create passed in 2.6s right before — so the command hung rather than being uniformly slow. Without logs we can't tell where.
Plan
- Keep the completion-time enforcement in
runBitsocialCommand's own timeout (unchanged at 10s/30s), but raise the vitest it timeouts so the subprocess's informative rejection is what fails the test.
- On subprocess timeout, additionally collect daemon-side diagnostics: tail of the daemon's captured stdout/stderr and tail of the daemon log file(s) in
logPath.
- Cap all tails so a failure message stays readable.
Problem
In CI run https://github.com/bitsocialnet/bitsocial-cli/actions/runs/33367427746/job/99410883648 (PR #139, windows-latest),
community list -q completes within 10stimed out, and the log contains zero information about why — no CLI output, no daemon output.Two gaps cause this:
runBitsocialCommandintest/cli/command-completion-time.test.tskills the child after 10s and rejects with an error that includes the captured stdout/stderr — but the vitest per-test timeout is also exactly10_000, so vitest's genericTest timed out in 10000msfires first (observed at 10015ms) and the informative rejection is never shown.--logPathin a temp directory that is never printed or uploaded, andstartPkcDaemonWithDynamicPortsonly prints captured daemon output if the daemon exits prematurely.For reference, on the last green master run the same test took 1.7s on windows, and in the failing run
community createpassed in 2.6s right before — so the command hung rather than being uniformly slow. Without logs we can't tell where.Plan
runBitsocialCommand's own timeout (unchanged at 10s/30s), but raise the vitestittimeouts so the subprocess's informative rejection is what fails the test.logPath.