fix(logging): stop the no-config window dropping every log line

[kriszyp]

Summary

This PR has been repurposed. It was opened to unbreak main's Format Check by reformatting unitTests/resources/query-array-scoping.test.js, and to fix the red Windows unit gate. #2468 landed both while this was in flight — the reformat is upstream, and main's Format Check and Windows gate are green. Rebased onto main, all of that is gone and what remains is the one thing #2468 left in place: the product bug underneath the Windows failure.

initLogSettings() falls back to a no-config branch on any host without a harperdb-config.yaml — the install window, and a fresh CI runner. It sets log_to_file = false; logToStdstreams = true, which reads as "the streams are the sink now", and then called createLogger() without passing stdStreams. createLogger destructures that option into a local of the same name, which shadows the module-level flag inside logStdOut/logStdErr — so the branch wrote nowhere at all. Before a config exists, every log line Harper produced was silently dropped, install diagnostics included.

That branch also returns before the stdioLogging() call at the end of initLogSettings(), so the streams it now writes to would have had no EPIPE/EIO listener: harper install | head -1 closes the reader and the async error lands on a stream with none, taking the install down. The guards are installed on that branch too; their write override is inert there, because log_to_file is false.

This is what the Windows gate was actually reporting when watcherFallback.test.js's warn-cadence case counted 0 of 2 warnings (#2364): the Ubuntu unit job runs harper install first and the Windows job does not, so only Windows had no config to read. #2468 gave that harness a config of its own — the right fix for the test — which leaves the product behaviour unchanged.

A child-process case pins both halves. It spawns with ROOTPATH at a directory holding no config, which reaches the fallback on an installed machine and a bare one alike (with boot properties present the config read throws ENOENT; without them initLogSettings() only swallows that failure when ROOTPATH does hold a config), and asserts the warning on stderr plus the guard listener on each stream.

For the human reviewer

• Close this instead if you would rather the logging fix land on its own branch — the CI goal it was opened for is already met by Stop the lost-watch harness aborting the Windows unit job on an 8.3 short temp path #2468, so nothing is lost by dropping it. The commit is self-contained.
• This changes product behaviour in the pre-config window, which is the part to weigh. Previously-silent logs now reach stdout/stderr, which is what the two lines above the call always intended. Two consequences you may want the other way, both one-liners I did not decide: notify/info route to stdout, so a CLI emitting machine-readable stdout before a config exists would interleave log lines with it (none does at those levels today); and the branch hard-sets logToStdstreams = true while its cmd/env loop honours only LOGGING_LEVEL/LOGGING_CONSOLE, so an operator's explicit LOGGING_STDSTREAMS=false is overridden in that window, where it was previously inert by accident.
• The alternative fix I did not take: rename the destructured local in createLogger so the module-level logToStdstreams stays visible and no caller can silently drop it. The shadow is the actual trap and it will re-fire on the next new caller — but the rename changes logStdOut's fallback semantics for every logger, which is a call for a human rather than a side effect of a CI fix.
• Coverage boundary: the new case asserts the guard listener is installed, not that a broken pipe is survived end to end. Closing the child's stdout reader and asserting survival would also exercise disableStdio(), which replaces the process-global nativeStdWrite and therefore mutes stderr along with stdout — worth its own change, not this one.
• Adjacent, pre-existing, filed rather than fixed here: logStdOut/logStdErr read the per-instance logger.logToStdstreams in the file branch but the closure capture in the no-file branch, while updateLogger writes only the property — so with logging.file: false, flipping stdStreams through the config watcher has no effect. Same option-plumbing trap, one level up. Also if (process.env.DEV_MODE) logToStdstreams = true runs after createLogger() in both branches, so it has been dead for the same shadowing reason.

Verification

• npm run test:unit:windows (the Windows gate's own group runner, on Linux) — all 9 groups pass, 3637 tests.
• The new case verified against both regressions it covers: reverting the createLogger() option fails it on the missing warning; removing the stdioLogging() call fails it on stdout-guard=true stderr-guard=true.
• Test style follows AGENTS.md — node:assert against a real child process, no sinon/rewire; the fallback branch is reachable by spawning with a config-less ROOTPATH, so there was nothing to stub.
• npx prettier --check . passes repo-wide; npx oxlint clean on the changed files.

Refs #2364, #2468

---

🤖 Generated with Claude Code

https://claude.ai/code/session_017gPFHKnh2qasUuy53fdzbe

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

_{Review-Coverage: authored=claude; ran=codex; adjudicated=domain; blocked=gemini(auth); declined=cursor-grok,cursor-composer; rounds=8 @ 521369e}

_{Human-Review-Need: 3 (decisions: epipe-survive-vs-crash, stdstreams-fix-at-callsite-vs-shadowing, child-process-fixture-vs-rewire) @ 521369e}

[gemini-code-assist]

Code Review

This pull request simplifies the formatting of two test assertions in unitTests/resources/query-array-scoping.test.js by condensing multi-line assert.deepStrictEqual calls into single lines. There are no review comments, and I have no feedback to provide.

[claude]

Reviewed; no blockers found.