The alarm lifecycle: turns a stream of per-bucket verdicts into incidents, and says which events to fire. Stateless, so one instance serves every tenant. All the state lives in the AnomalyAlarmState passed in, which the caller loads, hands over, and saves back. The re-notification window is applied at this layer rather than in the listeners, because this is the layer that knows the bucket interval: the right cadence for an hourly web-error detector is not the right cadence for a daily order-value detector, and a listener would have to reconstruct that from the event payload to get it right. It also means the window is configured once per detector instead of once per delivery channel. This is separate from, and coarser than, the coalescing inside AdminNotificationManager, which protects the notification queue from any misbehaving caller and works in minutes; this works in hours and is the policy for what an anomaly incident is worth saying.


Methods

accept(AnomalyAlarmState state, AnomalyResult result, AnomalyTripConfig trip, Date now)

Returns: AnomalyAlarmTransition

Account for one verdict, advancing the state and reporting what should be fired. Idempotent per bucket. A verdict for a bucket already accounted for changes nothing and fires nothing, which matters because the scheduler runs on a much shorter cycle than most detectors' buckets - an hourly scan of a daily detector sees the same closed bucket around two dozen times.

ParameterDescription
statethe detector's current position, modified in place. Must not be null
resultthe verdict for the newest closed bucket. Must not be null
tripthe hysteresis and re-notification settings. Must not be null
nowthe current instant, used for the re-notification window and the cleared timestamp. Must not be null
To get full access to the Kademi Hub existing customers can login here, or new customers can register here.