Alarm Pipeline Notify Block only sends email to first user in dynamic roster

Ignition
,
1

Hi everyone,

I am using an Ignition Alarm Pipeline and want to send email notifications using the Notify block.

The roster is built dynamically by a script:

logger = system.util.getLogger("sendMail")
recievers = system.tag.readBlocking("[internal]Services/email/recievers")[0].value

roster = []
for r in recievers:
    if isValidEmail(r["email"]):
        temp = { "username": r["username"], "email": [r["email"]] }
        roster.append(temp)
    else:
        logger.info(u"E-Mail: %s is not valid and will be ignored" % r["email"])

logger.debug("Send to: %s" % system.util.jsonEncode(roster))
return roster


import re

def isValidEmail(email):
    if email is None:
        return False

    email = email.strip()

    pattern = r'^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$'

    return re.match(pattern, email) is not None

The resulting roster looks like this:

[
  {
    "email": ["xxx@xx.com"],
    "username": "User1"
  },
  {
    "email": ["xxx@xxx.com"],
    "username": "User2"
  }
]

When I set the Notify block to Test Mode, the logs indicate that an email would be sent to both users.

However, when I disable Test Mode, only the first user in the roster actually receives an email. If I swap the order of the users in the roster array, then the other user receives the email instead. So it always seems to send only to the first entry.

I have also tried adding debug logs to find any errors, but there are no error messages or warnings in the logs.

Has anyone seen this behavior before, or does anyone have an idea what could cause the Notify block to only send to the first roster entry when Test Mode is disabled?

Thanks in advance!

2

I'd check if its something with your SMTP server having some kind of rate limit where it doesn't want to fire multiple emails at once.

If you have consolidation turned on in the alarm block maybe disable that, IIRC there was a minor bug in an older rev that caused issues with that but I don't think it's present in 8.3 so likely not going to help but it only takes a few seconds to try.

3

Thanks for your reply.

According to the log messages, Ignition does not even seem to attempt sending a second email. I enabled the debug logs for the email notification profile, and I only see the first email being sent. After that, I get a message saying that the notification was scheduled to the next user with +0ms, but then nothing else happens.

My understanding is that if the SMTP server rejected the second email because of a rate limit, I should see some kind of error or warning in the email notification profile logs.

Regarding consolidation: this is not enabled in my alarm block.

4

I also tested this with a roster that I created directly in Ignition, instead of using the calculated roster from the script. Unfortunately, the behavior is the same.

I also tried setting a send delay of 60 seconds in the Notify block. In that case I get the log message:

Scheduled notification to next user for +60000ms

Then, after about 60 seconds, I see:

Evaluation complete.

from the NoOpBlock logger.

However, between those two messages there are no additional log messages, and there is still no second Sending mail... entry.

So it looks like the pipeline schedules the next notification step, but when the delay expires it does not actually attempt to send the next email. Instead, the pipeline seems to continue/end without another email notification attempt.

5

I found the issue.

My test alarm was only active for a very short time. The first email was sent correctly, but by the time the Notify block was supposed to notify the second user, the alarm was already inactive/cleared. Because of that, no further users were notified.

After keeping the test alarm active for a longer period of time, all users in the roster were notified as expected.

So my understanding now is that the pipeline does not simply start once and then continue sending all notifications regardless of the current alarm state. Instead, it looks like the pipeline/dropout conditions are evaluated again between notifications, or at least before the next scheduled notification is sent.

This was not obvious to me from the documentation. The Notification Block documentation explains that the block waits between users when using “Delay Between Messages”, but I did not clearly understand from the Email section that the alarm/pipeline condition may be re-evaluated before the next user is notified.

So this was not an SMTP issue, not a calculated roster issue, and not a problem with the Notify block only handling the first user. It was caused by my test alarm clearing before the next notification was sent.