fix(watch): Treat an unparseable readiness file as not-ready-yet

[JordanCoin]

Found while investigating a CI failure on #175. Small, standalone — deliberately not folded into that PR, which touches only scanner/.

What's wrong

waitWatchReadiness (main.go:1154) returns on the first successful read:

data, err := os.ReadFile(path)
if err == nil {
    var status watchReadiness
    if err := json.Unmarshal(data, &status); err != nil {
        return fmt.Errorf("reading daemon readiness: %w", err)   // gives up
    }

A readiness file that exists but is empty or half-written reads successfully with zero or partial bytes, so the unmarshal fails and the wait aborts. Only os.ErrNotExist counts as "not ready yet".

Measured against the real function:

empty readiness file   -> reading daemon readiness: unexpected end of JSON input   after 0s
partial readiness file -> reading daemon readiness: unexpected end of JSON input

The 0s is the point: it doesn't wait out any part of the 30s timeout, it fails on the first poll.

An unparseable file is a file still being written, not a daemon that failed. Now the poll continues to the deadline, and the last parse error is surfaced if the deadline passes — so a file that never becomes valid still says why, rather than only that it timed out.

Scope, honestly

publishWatchReadiness already writes via temp-file + os.Rename, so codemap's own daemon does not open this window. This is the reader being brittle to any writer that isn't atomic — defence in depth plus test robustness, not a user-facing startup bug. I said otherwise in an earlier comment on #175 and have corrected it there.

What I could and could not verify

• Verified: the mechanism, directly against waitWatchReadiness (above), and that the fix makes it wait through a partial write and then honour the real content. Four tests cover: partial → real error, partial → success, persistent garbage → parse error surfaced, absent file → still times out.
• Not verified: that this resolves the CI failure that led me here (TestRunWatchStartWaitsForChildReadinessFailure on Test (ubuntu-latest, 1.24), fix(scanner): Resolve tsconfig alias targets written as "./*" #175). I could not reproduce that failure locally — 15/15 pass unloaded and 10/10 under CPU contention, on both main and the PR branch.

An earlier attempt of mine appeared to reproduce it at 20/20 on both branches. That measurement was wrong: I was running relocated test binaries from outside the repo, where they exit without running the test at all, so I was measuring my own harness rather than the test. Retracted rather than left standing.

What I do know: the CI error string is produced by exactly one code path, this one; the test's child is sh -c 'printf … > "$CODEMAP_WATCH_READINESS_FILE"', and > truncates the file into existence before printf writes it, which is precisely the window; and codemap/scanner passed in that same run while #175's diff touches nothing else. So this is the plausible cause and the fix is right on its own terms — but I'm not claiming it as proven.

Verification

go vet ./... clean, gofmt clean, go test ./... at the main baseline (only the three known root-environment permission failures).

🤖 Generated with Claude Code

https://claude.ai/code/session_01PEUvjGsJemDFSV8nbxvxBo

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[JordanCoin]

New evidence that strengthens this beyond what I could claim when I opened it.

I said the mechanism was confirmed but that I couldn't prove it caused the CI failure on #175, because I never reproduced that failure. Since then, a second, independent test hit the identical error — on #179, a PR that touches only scanner/walker.go:

TestRunWatchModeRunDaemonAndWatchStart/watch_start_shells_out_to_daemon_entrypoint
    main_more_test.go:1108: watch start failed:
        starting daemon: reading daemon readiness: unexpected end of JSON input

That's a different test, in a different subtest, on a different PR, with the same string — and the only code path that produces it is the one this PR fixes. Two unrelated tests landing in the same window is much harder to explain as coincidence than one.

It also sharpens how often this bites: it has now cost a CI leg on #175 and #179, and the sibling cargo-metadata timeout has cost #169, #170, #176 and #178. Between them, six legs across six PRs today.

Still stated precisely: I have not reproduced either occurrence locally (0/10 under load, 15/15 unloaded, on both branches), so this remains the cause consistent with all the evidence rather than one I've triggered on demand. The change stands on its own terms regardless — an unparseable file is a file still being written, not a daemon that failed.

I've ported it into #179 alongside the cargo fix so that PR can go green without waiting on this one.

---

Generated by Claude Code