fix(log): emit the buffered lines `Flush()` dropped by shouples · Pull Request #3464 · confluentinc/cli

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) · 2026-08-21T18:55:49Z

Release Notes

Bug Fixes

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

Checklist

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 · 2026-08-21T18:56:00Z

🎉 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.}

Flush replays buffered messages once verbosity is raised (a message logged before -v is parsed, say). The filter was `lm.level < l.Level`, but a higher Level value is more verbose, so it skipped exactly the messages now within the threshold and emitted the rest. Corrected to `>`, with a regression test that logs at DEBUG, raises verbosity, and asserts the message appears. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

sonarqube-confluent · 2026-08-27T20:02:36Z

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

Dave Shoup (shouples) changed the title ~~fix(log): emit the buffered lines Flush() dropped~~fix(log): emit the buffered lines Flush() droppedAug 21, 2026

airlock-confluentincBotforce-pushed the djs/migrate-mocker-to-mockgen branch from 4cf1925 to f40d677Compare August 27, 2026 19:37

airlock-confluentincBotforce-pushed the djs/fix-log-flush branch from 952f86d to bfef0c2Compare August 27, 2026 19:38