Repository navigation
Edit bursts longer than 1s roll the gateway once per second #10
Description
Problem
The event handler calls q.AddAfter(key, Settle) (setup.go#L33). controller-runtime's priority queue keeps the earliest ready time for repeated adds, so the first event opens a fixed 1s window and later events never extend it.
Reproduce (real manager)
| Burst | Secret writes and stamps |
|---|---|
| 20 Models back to back | 1 |
| 20 Models, 100 ms apart (2.1 s) | 2 |
| 8 Models, 400 ms apart (3.2 s) | 3 |
Impact
Roughly one rollout per second of burst. GitOps sync waves get one per wave. Each new stamp supersedes the rollout in flight, adding pod churn (30 s preStop each) and resetting in-memory rate-limit counters. Every intermediate file is valid.
Scores
| Reproducibility | Likelihood | Severity | Existing mitigations | Detectability | Test coverage | Fix cost vs benefit |
|---|---|---|---|---|---|---|
| 10 | 5 | 3 | 2 | 5 | 1 | 6 |
Scores are out of 10. Higher is worse for likelihood and severity. Higher is better for mitigations, detectability, test coverage and cost vs benefit (10 = cheap fix, high value).
Fix
Trailing debounce with a cap: record first and last event times in the handler, and have Reconcile return RequeueAfter: Settle - sinceLast while sinceLast < Settle and sinceFirst < MaxWait (around 10 s). Ignore events caused by the controller's own Secret write and Deployment stamp, so a rollout's pod churn doesn't keep extending the window.
Tests to add
A manager test asserting a 3 s burst produces one stamp.
Activity