fix: apply PLUK_LOG_MAX_BYTES cap even when the log has fewer than PLUK_LOG_KEEP_LINES lines

[hivecommons-hive]

Removes the early return in rotateLogFileIfNeeded that skipped the byte-cap loop when the log had <= keepLines lines. Returns false only when nothing is dropped (e.g. single oversized line). Updates the pinned fallback test, adds a regression test and changelog entry.

Closes #283

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hivecommons-hive]

hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Read rotateLogFileIfNeeded at ab723a7 (src/run-dir.ts:153-227) and its single caller (src/cli.ts:212). This looks correct to me.

Checked the new early return (src/run-dir.ts:190, drop === 0 && kept.length === usableLines.length) against each path:

• Fewer than keepLines lines, over maxBytes (the #283 case): kept is the whole file, the while loop at :186 drops oldest lines until it fits, drop > 0 → rewrite. New test in test/run-dir.test.js:252 pins it; byte math (8 bytes/line, 20-byte cap → last two lines) is right.
• More than keepLines lines, already under maxBytes after the line trim: drop === 0 but kept.length < usableLines.length → still rewrites. The pre-existing line-trim behaviour is preserved.
• Single line that alone exceeds maxBytes: loop condition drop < kept.length - 1 is false immediately, kept.length === usableLines.length === 1 → false. Matches the doc comment at :147-149 and the existing "never drops the newest line" test.
• Under maxBytes: already short-circuited at :166, unchanged.

README PLUK_LOG_KEEP_LINES row (README.md:92) already describes the post-fix contract ("within the PLUK_LOG_MAX_BYTES cap"), so no docs change is needed. The rewritten test/default-fallbacks.test.js case was pinning the bug, not a feature, so replacing it is the right call.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Reviewed — no findings from this perspective.

— hive: agent=adjudicator backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Reviewed — no findings from this perspective.

— hive: agent=ci-maintainer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Reviewed — no findings from this perspective.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Reviewed — no findings from this perspective.

— hive: agent=adjudicator backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Hive filed review findings that do not block this PR as backlog items:

• [scanner] fix: log rotation skips the PLUK_LOG_MAX_BYTES cap when the log has fewer than PLUK_LOG_KEEP_LINES lines #283 — Review backlog (docs-currency): Runbook describes rotation as keeping PLUK_LOG_KEEP_LINES lines without mentioning the byte cap ([scanner] fix: log rotation skips the PLUK_LOG_MAX_BYTES cap when the log has fewer than PLUK_LOG_KEEP_LINES lines #283)

Cap: 10 backlog item(s) per PR per day.

[hivecommons-hive]

Evidence bundle `#284ab723a7` sha256:4381e7c772e3ad3e7d6e02850321741b3b4a9424976a38970a53136dd6ee9726 — download from the dashboard or `hivectl review evidence #284`.

[github-actions]

Thank you for your contribution! Your PR has been merged.

We'd love to hear how your experience was: share feedback