fix(logging): external/component loggers inherit main rotation config

[kriszyp]

Summary

updateLogger() unconditionally set logger.rotation = logOptions.rotation, so an external or component logger configured with its own path but no rotation block of its own lost rotation entirely — instead of inheriting logging.rotation (including maxSize) from the main logger, as documented ("all components default to the main logging configuration unless overridden"). This let hdb.log grow unbounded even with logging.rotation.maxSize set (reported as a 200G log file).

Fix: fall back to mainLogger.rotation when a logger's own options don't specify rotation, mirroring the existing level/path fallback pattern already in the same function — excluding the main logger itself so its own rotation can still be cleared by omitting the rotation block from config.

Refs #1877

Where to look

• utility/logging/harper_logger.ts updateLogger() — the one-line root cause + fix.
• unitTests/utility/logging/harper_logger.test.js — new describe('Test external/component logger rotation inheritance (#1877)') block: proves inheritance (incl. maxSize) with an actual file rotation (condition-waited, not a fixed sleep), that an explicit component-level { enabled: false } override is preserved, and that the main logger's own rotation can still be cleared.

Cross-model review

Ran the Gemini leg (standard mode); the reviewer/codex-reviewer subagents aren't installed in this headless worker, so findings were adjudicated inline (noted as a caveat, per the skill's fallback protocol). Two real findings were fixed as part of this PR:

• A self-referential edge case where mainLogger?.rotation read back its own current value when logger === mainLogger, making it impossible to ever clear the main logger's own rotation via config — excluded that case explicitly.
• New tests reassign a logger's .path mid-test, which left the public logger's .closeLogFile bound to a stale file entry; afterEach now closes every registered file logger via the module's internal registry before removing the test directory.

One suggestion (shallow-cloning the inherited rotation object instead of sharing the reference) was assessed and not applied — no code path in this file currently mutates a rotation config object in place after assignment, so cloning would be unused defensive complexity.

Test status

npm run test:unit:logging, test:unit:main, test:unit:resources all pass. npm run build has one pre-existing, unrelated tsc error in resources/DatabaseTransaction.ts present on origin/main before this change (confirmed via git stash) — dist still emits despite it (noEmitOnError is not set), so it doesn't block this PR, but it's worth a separate fix since this repo's build is supposed to be clean.

Docs

No documentation change — the fix makes the code conform to the existing documented behavior (component loggers default to main logging config unless overridden); the docs were already correct.

---

Generated by Claude Sonnet 5 (dev-agent, dispatch harper-1877).

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the updateLogger function in utility/logging/harper_logger.ts to allow external or component loggers to inherit the main logger's rotation configuration when they do not define their own. It also ensures that the main logger's rotation can still be cleared without getting stuck in a self-referential fallback. Additionally, comprehensive unit tests have been added to verify this inheritance behavior, explicit overrides, and the ability to clear the main logger's rotation. There are no review comments, and I have no feedback to provide.

[claude]

Reviewed; no blockers found.

[claude]

Suggestion (non-blocking): Date.now is frozen at line 180 before waitFor is called, but waitFor's own deadline (unitTests/waitFor.js) is computed as Date.now() + timeout — with the clock frozen, that deadline never advances, so the Date.now() >= deadline timeout check can never trip. If this test's collision fix ever regresses (only one archive lands in sharedRotatedDir), this waitFor won't produce its intended friendly assert.fail(message) — it'll spin until Mocha's own .timeout(TEST_TIMEOUT) kills it with a generic timeout error instead. Consider restoring the real Date.now (or computing the deadline from the real clock before freezing) around this waitFor call so the bounded-wait/friendly-message behavior still works on a regression.