Triggers and Alerts in continuation of previous alert state

Together with release for continuation of alerts:

https://mydevices.atlassian.net/browse/SS-10497

There were several issues solved:

https://mydevices.atlassian.net/browse/SS-10494

Alerts Stuck in Continuation State https://mydevices.atlassian.net/browse/SS-10471 REVIEW

At the basis the core issue was that several customers complained about their alerts keeping in continuation state and not receiving a new alert when they should.

After code review it looked like 2 involved fields in the logic of alerts were not being reset:

      last_triggered_log_id: null,
      last_sent_notification: null,

Also these fields were not reset for the moment when the rule was enabled/disabled and this meant the rule was still continuing it’s old behaviour instead of reseting it’s state at it should be in our app logic.

In order to have code coverage for this rule another automated test was implemented:

Should re-enter alert state and send only one notification

Also one important logic was updated previousAlertState

  previousAlertState =
      (triggerRule.triggered &&
      triggerRule.is_offline === false &&
      gateway === false &&
      triggerRule.last_triggered_log_id !== null && //SS-9730 - newly added alerts would not work first time
        triggerRule.notify === 'ONCE') ||
      triggerRule.notify === 'OFF';

The logic itself is heavy to debug but it takes the decision if it should send a notification or not.

So there are 2 main cases when a notification is not being sent:

A. There is continuation alert type of rule named “ONCE”. The rule is already triggered, it’s not a gateway or offline rule and has last triggered log id empty. This was the main cause creating the bugs reporting by our customers.

B. notification is totally disabled with “OFF”

For the “REPEAT” type of rules a notification is always submitted. These alerts are also named “legacy alerts”

Another important fix was setting last sent notification conditionally by the previous alert flag:

So there are two cases:

A. If the rule is already in continuous state(previous alert state) it should save the old timestamp and keep only that so UI can display when it started.

B. If the rule is newly triggered it should set this to the newest timestamp(closest to NOW)

For the overall check of other rules failing on prod there is also a script written that can reset states for alerts that should not be triggered and solve this issue for previous customers:

The script can be for the entire database and reset the state of the rule to the actual rule triggered: true(RED) or false(GREEN).

Support & QA

Triggers and Alerts in continuation of previous alert state

Analytics

Related content