feat(limit): drop resolved alerts without an admitted firing counterpart - #5381
Open
siavashs wants to merge 3 commits into
Open
feat(limit): drop resolved alerts without an admitted firing counterpart#5381siavashs wants to merge 3 commits into
siavashs wants to merge 3 commits into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe change adds removal support to per-alertname limit buckets, handles resolved alerts only when their firing alerts were admitted, migrates provider and store APIs to ChangesAlert limits and type migration
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant AlertInput
participant store.Alerts
participant limit.Bucket
participant provider.mem
AlertInput->>store.Alerts: Submit alert.Alert
store.Alerts->>limit.Bucket: Admit firing or remove resolved fingerprint
limit.Bucket-->>store.Alerts: Return limit result
store.Alerts-->>provider.mem: Return stored alert or limitError
provider.mem->>provider.mem: Record state-labeled limit metric
Merge Risk: ⚪ Minimal · up to The change limits firing alerts, forwards only matching resolutions, frees admitted slots, and labels limited-alert metrics by state. The supplied tests cover these behaviors, so no actionable merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 19.05% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 21 functions across 6 files. (2 skipped: 2 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ultrotter
reviewed
Jul 14, 2026
| // If the bucket is full, oldest expired item is evicted based on priority and the new value is added. | ||
| // Otherwise the new value is ignored and the method returns false. | ||
| func (b *Bucket[V]) Upsert(value V, priority time.Time) (ok bool) { | ||
| if b.capacity < 1 { |
Contributor
There was a problem hiding this comment.
Do we need this check? Would there be a point for a capacity 0 bucket? Should we fail at NewBucket instead in that case?
Contributor
Author
There was a problem hiding this comment.
The bucket limiter was added as a generic implementation, zero here means drop all, we can change it in future to allow all.
siavashs
force-pushed
the
feat/limit-resolved-alerts
branch
from
August 17, 2026 09:17
d71ba20 to
74c0127
Compare
Rework the per-alertname alert limit so resolved notifications no longer consume limit slots, and change how they are handled. - limit: add Bucket.Remove to free a tracked slot by value/fingerprint. - store: apply the per-alert limit only to firing alerts. A resolved notification is forwarded only if its firing counterpart was previously admitted (its fingerprint is still tracked); removing it frees the slot the firing alert was holding. Resolves with no admitted firing are dropped as noise, since nothing downstream ever received a firing for them from us. - provider/mem: add a `state` label (firing/resolved) to alertmanager_alerts_limited_total so dropped firing alerts and dropped resolved notifications can be distinguished. - docs: document the new resolved handling and metric label in alertmanager.md and configuration.md. - tests: add Bucket.Remove coverage (presence return, slot freeing, double remove, heap eviction-order integrity, concurrency) and store coverage for the drop-if-unseen resolved semantics. Signed-off-by: Siavash Safi <siavash@cloudflare.com>
siavashs
force-pushed
the
feat/limit-resolved-alerts
branch
from
August 17, 2026 11:37
74c0127 to
4d4ecc3
Compare
Resolve the release-note and alert-limit documentation conflicts against current main. Signed-off-by: Siavash Safi <siavash@cloudflare.com>
Carry the store limit decision in the returned error so metric labels do not depend on a later time check. Use alert terminology for incoming resolved alerts. Signed-off-by: Siavash Safi <siavash@cloudflare.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rework the per-alertname alert limit so resolved notifications no longer consume limit slots, and change how they are handled.
statelabel (firing/resolved) to alertmanager_alerts_limited_total so dropped firing alerts and dropped resolved notifications can be distinguished.Pull Request Checklist
Please check all the applicable boxes.
benchstatto compare benchmarksWhich user-facing changes does this PR introduce?