How to prevent a Rules Action to happens twice using Rules Event User account validated?

Question

I've set up a rule that sends you an HTML email when you activate your account. It seems to throw back a notification about:

Notice: Undefined variable: attachment in SmtpMailSystem->mail()

But it seems to send the email anyway, but what I don't understand is that I receive 2 emails everytime I test it. I've checked the log files and it seems to log that an anonymous user has used the validate URL to confirm their email address, then sends the email. Then it opens up a session for this new user, and then sends them the email again.

I've set the rule to run on 'When the user account is activated' and if I turn the rule off I get no emails, so it isn't that there is anything else sending an email too, it is only this rule, it just seems to do it twice.

Can anyone offer a solution?

I'm using the SMTP, Mimemail and Mail System modules

If anyone needs me to post any specifics about the rule, or the error or the email text etc, just ask, I just didn't want to flood the post with huge blocks of code if it might not have helped.

EDIT1

Log file output (obviously I have flipped the order for it to make sense, log files are recent most recent first)

• New user: unset_username (fake@email.com). // When I create a new account
• Sending mail to: "Firstname Lastname" // Emails out the verification request
• E-mail validation URL used for Firstname Lastname with timestamp ...
• Sending mail to: "Firstname Lastname" // Emails out the confirmation email once
• Session opened for Firstname Lastname.
• Sending mail to: "Firstname Lastname" // Emails out the confirmation email again

EDIT 2

Determined the issue is nothing to do with the emails, tried re-creating the rule but sending an output to the page rather than sending HTML email, it was confirmed that this rule runs twice (and hence nothing to do with emails in particular) by the fact that the message was output twice as well.

UPDATE

As Molot has pointed out this isn't anything to do with emails, just the rule happening twice. I'll leave the text above incase anyone else is trying to send out emails on verification and they come to the same conclusion I did, so they can find this and understand whats happening.

Answer 1

Understanding what's happening

Your question seems like a variation (IMO not a duplicate) of the question 'Why is my rule that reacts on event "After updating an existing user account" firing twice?'. The accepted answer in that question might help to understand your issue (what's causing it) also, ie:

some other module code is calling a user_save on hook_user_update triggering the rules event a second time.

If I was to debug this, I'd disable all contributed modules (except "Rules" and "Entity API") to check if it's indeed a contributed module (I don't expect it to be core). And then re-enable the contributed modules one by one until the issue comes back. As soon as it comes back, you pinpointed the contributed module causing the issue, and you can start working on a possible remedy for that.

Workaround 1

That question also has another answer with a very interesting workaround, with an image which looks like so (a picture is worth more then 1000 words):

Workaround 2

Another workaround to prevent this issue from happening, is to improve your existing rule to make it similar to the rule included in my answer to "How to implement a Rules Condition like [account:last-login] = never?". More specifically:

• Add a Rules Condition like: User does NOT (!!!) have a role with role id = "4".
• Add a Rules Action like: Grant User the role with role id = "4".

So this improvement of your rule will check if the user does not yet have some (designated) role with role id = "4" (adapt to whatever role id that fits your case, and make sure this role is NOT yet granted when activating a new user id). If that's the case, then the user is granted that role. With this improvement to your existing rule, this is what will happen:

• The 1st time your Rules Actions will still be performed (and grants the designated role).
• the 2nd time not ALL of your Rules Conditions will be satisfied (since the designated role was granted before), and therefor your Rules Actions will no longer be performed.

In other words: "this will prevent your Rules Actions to happen twice" (as in your question).