Flaky CI: logs -f follow tests and kubo restart-race test fail under CI runner load

[Rinse12]

Summary

Two timing-sensitive integration tests fail intermittently on loaded CI runners (observed on master CI run 27133947713). Both pass reliably locally.

Failures observed

1. macos — test/cli/logs.test.ts:462 › "continues watching old file if no new file appears": stdout contained the initial line but not APPENDED_LINE.
2. ubuntu — test/cli/daemon-kubo-restart-race.test.ts:262 › "kubo is killed on SIGTERM even when a signal-exit handler registered after the exit hook": expect(kuboRestarted).toBe(true) (setup precondition) timed out. Ran 43.8s on CI; passes in ~13s locally.

Root cause

• logs -f tests: the 8s SIGINT kill timer is anchored to process spawn. The budget must cover CLI cold-start (oclif/pkc-js import, which can be several seconds) + printing the initial marker + detecting the file change + flushing the second marker. On a slow runner, startup eats the budget and the process is killed before the awaited line is emitted. All three tests in the bitsocial logs -f (file rotation) block share this pattern.
• restart-race test: the restarted-kubo detect window (waitForCondition, 30s) is too tight given the test injects PKC_CLI_TEST_IPFS_READY_DELAY_MS=5000 and the runner may be heavily loaded with parallel kubo nodes. The overall test timeout is 120s, so there is headroom to widen.

Fix

• logs -f tests: kill as soon as the awaited output is observed, with a generous safety-cap timeout instead of a fixed 8s wall.
• restart-race test: widen the restarted-kubo detect window to account for the injected ready delay + runner load.

These are test-harness robustness fixes; no production code change.

[Rinse12]

PR #78 opened with the fix on branch test/harden-flaky-follow-restart-tests (off master).

• logs -f tests: replaced fixed 8s spawn-anchored kill timer with a shared runFollowUntil() helper that kills on observed output (25s safety cap).
• restart-race test: widened restarted-kubo detect window 30s → 60s.

Verified locally: logs.test.ts 29/29 pass, daemon-kubo-restart-race.test.ts 4/4 pass. Awaiting CI on the PR.

[Rinse12]

Root cause found and fixed (not a test bug)

The logs -f "continues watching old file" failure is a real product race in src/cli/commands/logs.ts, confirmed by the diagnostics I added (which fired on the windows job) and then reproduced locally under CPU saturation.

The follow code set its starting byte offset from a separate fsPromise.stat() taken after the initial readFile + parse + stdout write:

const existingContent = await readFile(file)   // reads N bytes, prints them
...parse/filter/write to stdout...             // <- an append can land here
const stat = await stat(file)                  // size now N+M
let position = stat.size                        // = N+M, skips the M new bytes

Any append that lands between the readFile and the stat is silently dropped: those bytes were never in the dumped content, and position jumps past them, so the 300ms poll loop never re-reads them. Under load the gap between the two awaits widens — which is why it failed intermittently on all three platforms, not just one.

The follow-trace showed position==observedSize==81 (whole file incl. the append) from the first poll with bytesThisCycle=0 forever — position had already skipped the unread append.

Fix (commit 35a1cdb): anchor position to Buffer.byteLength(existingContent) — the exact bytes we just read — before any further awaits. Anything appended afterward is at offset >= position and is picked up by the poll. Verified 20/20 green under 48-process CPU saturation that previously reproduced the drop within ~2 runs.

Note: this also means real users could intermittently miss a log line appended during logs -f startup; the fix closes that for them too.

Earlier commits on the PR also fixed: the logs -f fixed-window fragility, and the daemon.test.ts/daemon-kubo-restart-race.test.ts restart-detect windows + a diagnostics-on-wrong-assertion gap.

[Rinse12]

Heads-up: PR #78 merged the test hardening + diagnostics, but the actual root-cause fix landed on the branch after #78 had already merged, so it did not reach master. Opened PR #79 with just the logs.ts race fix (cherry-picked onto master). #77 stays open until #79 merges.