Skip to content

Warn and skip the notifier worker when alerts are disabled - #93

Merged
LarsLaskowski merged 2 commits into
mainfrom
claude/issue-72-elgt3g
Aug 18, 2026
Merged

Warn and skip the notifier worker when alerts are disabled#93
LarsLaskowski merged 2 commits into
mainfrom
claude/issue-72-elgt3g

Conversation

@LarsLaskowski

@LarsLaskowski LarsLaskowski commented Aug 18, 2026

Copy link
Copy Markdown
Owner

📖 Description

With alerts.enabled: false but alerts.webhooks populated, the notifier was built and its delivery worker started (cmd/pimonitor/main.go, internal/collector/collector.go), but the disabled alert engine never produces transition events — the webhooks silently never fired, with no indication why.

This is a fix, not a breaking change.

🎫 Issues

Closes #72

👩‍💻 Reviewer Notes

Two changes:

  1. internal/collector/collector.go: Collector.New now only wires cfg.Notifier into the collector when cfg.AlertsEnabled is true, mirroring how the alert engine itself is already gated. This means Run never calls notifier.Start for a disabled engine — the idle worker is no longer started at all (as opposed to running but never receiving events).
  2. cmd/pimonitor/main.go: logs a startup warning — "alert webhooks configured but alerts.enabled is false — no notifications will be sent" — when a notifier was built (i.e. webhooks are configured) but alerts.enabled is false, so the inert combination is visible instead of silent.

internal/config/config.go's Alerts.validate() is untouched: it still validates webhook config regardless of enabled, which is correct (a typo in an inert config should still fail fast at startup).

📑 Test Plan

Added TestCollector_Notifier_NotWiredWhenAlertsDisabled in internal/collector/collector_test.go, which builds a real notifier from a configured webhook via alert.NewNotifier, constructs a Collector with AlertsEnabled: false, and asserts the collector's internal notifier field stays nil — i.e. the worker is never wired in to be started.

  • go build ./... — clean
  • go vet ./... — clean
  • go test ./... -race -cover — all packages pass
  • golangci-lint run — 0 issues

The startup warning log line itself is a simple log.Warn call in main.go's run(), consistent with other untested log statements already in that function (e.g. the shutdown log); it is not independently unit-tested.

✅ Checklist

General

  • I have added/updated tests for my changes (go test ./... -race -cover passes locally).
  • go vet ./... and golangci-lint run are clean.
  • I have tested my changes.
  • I have read the CONTRIBUTING documentation and followed the project's code style guidelines.
  • I have updated ARCHITECTURE.md if this changes a documented design decision. (not applicable — no design decision changed)

REST API / configuration / packaging

Not applicable — no REST API, config schema, or packaging change.

⏭ Next Steps

None.

claude added 2 commits August 18, 2026 17:41
With alerts.enabled=false but alerts.webhooks configured, the notifier
was still built and its delivery worker started even though the
disabled alert engine never produces events for it to deliver — the
webhooks silently never fire, with no indication why.

Gate wiring the notifier into the collector on AlertsEnabled, mirroring
how the alert engine itself is already gated, so the idle worker is
never started. Also log a startup warning when webhooks are configured
alongside alerts.enabled=false, so the inert combination is visible.
Pull the alerts.enabled=false-but-webhooks-configured warning check
out of run() into warnIfNotifierInert, and add TestWarnIfNotifierInert
covering all three cases (no webhooks, webhooks with alerts enabled,
webhooks with alerts disabled). run() itself has no test harness, so
this keeps the new logic itself verifiable in isolation.
@sonarqubecloud

Copy link
Copy Markdown

@LarsLaskowski
LarsLaskowski merged commit d694247 into main Aug 18, 2026
5 checks passed
@LarsLaskowski
LarsLaskowski deleted the claude/issue-72-elgt3g branch August 18, 2026 17:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Config UX: webhooks configured while alerts.enabled=false silently never fire

2 participants