[Starosdev]

Summary

A degraded MDADM array was announced only on the transition from healthy, and the alert was lost for good if that one delivery failed. This makes MDADM notifications honor Repeat Notifications and retry until delivered.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• CI/CD or infrastructure change

Related Issues

Fixes #1109

Changes Made

• Add MDADMTracker to the notification gate (notify/mdadm.go). It records, per array, the degradation last announced, and records it only when TrySend reports the notification delivered or queued. A send error or a rate-limit drop is retried on the next collection.
• Repeat Notifications on: every collection notifies while the array stays degraded, consistent with SMART failures.
• Repeat Notifications off: notify when the array becomes degraded, and again when it loses an active member or gains a failed one. An improvement becomes the new baseline, so a later relapse is announced. A healthy upload clears the record.
• The tracker compares active and failed member counts, not the State string. mdadm flips clean and active with write activity, so comparing the string would re-announce an unchanged degradation. A state change with the same counts, such as the start of a rebuild, is therefore not announced.
• Remove the InfluxDB history lookup from the notification path. It also caused an accidental repeat on every run when collections were more than a day apart, because the day window then held a single point.
• Document the notification behavior and the permanently degraded Synology md0/md1 system and swap arrays in docs/MDADM_MONITORING.md.

The tracker state is in memory, like the other notification dedup state (rate limit, quiet queue, collector errors, missed ping, temperature). A web server restart announces each array that is still degraded once more. Persisting it was considered and rejected to stay consistent with that rule and avoid a migration.

• Merge develop after feat(btrfs): notify on degraded filesystems, device errors and scrub errors #1127: keep sendNotificationWithGate with the signature feat(btrfs): notify on degraded filesystems, device errors and scrub errors #1127 introduced, now returning whether the notification was delivered or queued. The Btrfs path calls it unchanged.

Testing

• I have tested this locally
• I have added/updated tests that prove my fix/feature works
• All existing tests pass

Local: go build ./... and go vet ./web/handler ./notify pass (vet compiles the tests). Tests were not run locally; CI runs them.

New tests: six MDADMTracker tests (single announcement, repeat on, retry after failed delivery, worsening, relapse after improvement, re-announce after recovery) and handler tests for mute, the unmuted path, and forgetting on a healthy upload.

Checklist

• My code follows the project's code style
• I have performed a self-review of my code
• I have commented my code where necessary (particularly complex areas)
• I have updated the documentation if needed
• My changes generate no new warnings
• No console.log, debug statements, or commented-out code

Additional Notes

Review: not required (merging to develop ships nothing until a manual release; no migration, security boundary, or shared contract change).

Not included: a hint in the MDADM page or notification text about Synology system arrays. Adding it to every notification would add noise to real alerts; the docs entry and the existing mute cover it for now.