fix(log): emit the buffered lines Flush() dropped

[Dave Shoup (shouples)]

Release Notes

Bug Fixes

• Fixed verbose logging (-v) dropping buffered log lines it should have emitted, and emitting the low-priority ones instead.

Checklist

• I have successfully built and used a custom CLI binary, without linter issues from this PR.
• I have clearly specified in the What section below whether this PR applies to Confluent Cloud, Confluent Platform, or both.
• I have verified this PR in Confluent Cloud pre-prod or production environment, if applicable.
• I have verified this PR in Confluent Platform on-premises environment, if applicable.
• I have attached manual CLI verification results or screenshots in the Test & Review section below.
• I have added appropriate CLI integration or unit tests for any new or updated commands and functionality.
• I confirm that this PR introduces no breaking changes or backward compatibility issues.
• I have indicated the potential customer impact if something goes wrong in the Blast Radius section below.
• I have put checkmarks below confirming that the feature associated with this PR is enabled in:
  • Confluent Cloud prod
  • Confluent Cloud stag
  • Confluent Platform
  • Check this box if the feature is enabled for certain organizations only

Applies to both Cloud and Platform (shared logging). Feature-flag items are N/A - this is a bug fix, not a gated feature.

What

The CLI buffers log lines and flushes them later (for example, to attach context to an error). The flush filter that decides which buffered lines to emit was inverted, so it dropped exactly the lines it should have kept - the more important, less verbose ones - and emitted the rest.

pkg/log/logger.go's Flush() had if lm.level < l.Level { continue }. Higher level values mean more verbose, so a buffered line should be emitted when its level is at or below the current threshold (lm.level <= l.Level), not skipped when it is below. The one-character fix flips the comparison to >, and a regression test pins the behavior so it cannot silently invert again.

Same command at -vvv (verbosity = DEBUG), with four lines buffered before verbosity was parsed:

# before (buggy `<`): drops the WARN and INFO lines the user should see
[DEBUG] debug: low-level detail

# after (fixed `>`): everything at or below the requested level is emitted
[WARN]  warn: rare but handled
[INFO]  info: steady-state
[DEBUG] debug: low-level detail

(TRACE is correctly withheld in both - it is more verbose than the requested DEBUG.)

Applies to: both Confluent Cloud and Confluent Platform (shared logging code).

Blast Radius

Very small, and confined to diagnostic logging. The logger writes only to stderr, and Flush() runs once at startup purely for its logging side effect - it returns nothing and touches no command result, exit code, or stdout, so machine-readable output (-o json / -o yaml) is unaffected. If the filter were wrong, the effect is limited to which buffered lines land on stderr, and only in the under-emitting direction: the per-level emit methods re-gate each line, so a wrong filter still cannot surface a line more verbose than the active level (credential-bearing UNSAFE_TRACE output stays gated behind --unsafe-trace regardless). No customer-facing command would break.

References

• Stacked on the migrate-mocker-to-mockgen base; part of a small logging-fix stack.

Test & Review

• Added a regression test in pkg/log/logger_test.go asserting Flush() emits buffered lines at or below the threshold and drops the more-verbose ones.
• A/B verified by hand: at -vvvv, the same command emitted 0 buffered [DEBUG] lines before the fix and 4 after.
• go test ./pkg/log/... passes.

[confluent-cla-assistant]

🎉 All Contributor License Agreements have been signed. Ready to merge.
_{Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.}

[sonarqube-confluent]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube