Follow-up from #47's review (pre-existing behavior, not a regression from that PR).
gatekeeper.go's configureLogging fans every slog record out to otelslog.NewHandler("gatekeeper") unconditionally — the bridge's Enabled() defers to the OTel logger, not the configured console level. So the DEBUG line that #47's logOTelError emits on a failed export is itself enqueued into the same OTel logs export pipeline that just failed: failed export → DEBUG diagnostic → re-enqueued → next export fails carrying it → another diagnostic, indefinitely while the collector is unreachable.
Steady-state and bounded (one record per export attempt; the batch queue drops on overflow), and it existed before #47 (the old INFO-level records took the identical path). Worth breaking properly, e.g. by excluding gatekeeper's own OTel diagnostic records from the otelslog bridge (a marker attribute the multiHandler filters, or a dedicated non-bridged logger for OTel diagnostics).
Follow-up from #47's review (pre-existing behavior, not a regression from that PR).
gatekeeper.go'sconfigureLoggingfans every slog record out tootelslog.NewHandler("gatekeeper")unconditionally — the bridge'sEnabled()defers to the OTel logger, not the configured console level. So the DEBUG line that #47'slogOTelErroremits on a failed export is itself enqueued into the same OTel logs export pipeline that just failed: failed export → DEBUG diagnostic → re-enqueued → next export fails carrying it → another diagnostic, indefinitely while the collector is unreachable.Steady-state and bounded (one record per export attempt; the batch queue drops on overflow), and it existed before #47 (the old INFO-level records took the identical path). Worth breaking properly, e.g. by excluding gatekeeper's own OTel diagnostic records from the otelslog bridge (a marker attribute the multiHandler filters, or a dedicated non-bridged logger for OTel diagnostics).