Improve recursion prevent to cover saves of other rules as well

Experiencing similar behavior. I have two Rules that are firing a single email per rule. When both are enabled, I get 4 emails (should be 2). When I disable one of them, I get 1 email (should be 1).

Rules evaluation log-Close all-
" Reacting on event After updating existing content.
0 ms Reacting on event After updating existing content.
47.74 ms Evaluating conditions of rule Creating, Updating, Deleting. [edit]
47.765 ms AND evaluated to TRUE.
" Rule Creating, Updating, Deleting fires. [edit]
176.865 ms Evaluating conditions of rule Creating or Updating. [edit]
176.907 ms AND evaluated to TRUE.
" Rule Creating or Updating fires. [edit]
191.273 ms Evaluating conditions of rule Updating Content. [edit]
191.293 ms AND evaluated to TRUE.
" Rule Updating Content fires. [edit]
417.314 ms Saved node of type node.
" Reacting on event After updating existing content. [edit]
650.116 ms Finished reacting on event After updating existing content.

Reacting on event "After updating existing content" fires twice. Resulting in sending 2 e-mails (and evaluating ALL rules associated with this event twice).

Thanks,

Andrew

Experiencing this issue too...

I have this problem also.

I have two rules I want to fire after creating/editing a particular content type:
1) Set the data in a field automatically based on another field (for example, a taxonomy term is automatically created based on one of the fields), using a 'Set a data value' action.
2) Create a record in a custom database table, using an 'Execute custom PHP code' action.

I reviewed the Rules evaluation log after editing an existing page for this content type.

An After updating existing content event occurs and both rules are correctly evaluated and fired.

Then another After updating existing content event occurs. My first rule does not fire again. The evaluation log says "Not evaluating reaction rule MyRuleName to prevent recursion." But my second rule does fire again, creating a duplicate record in my custom database table.

It is strange that one rule correctly doesn't fire again "to prevent recursion", but the other rule does fire again.

Hi,
I have this problem also when using the event "after updating existing content"
I'm using the current Rules dev version.
With the event "Before saving content" I have exactly the same issue

Experiencing this issue as well

Same issue here. I have a rule that publishes unpublished nodes after they are saved and another rule to send email after updating existing content. I receive two emails after an unpublished node is saved. If the node is already published, I only receive one email after updating existing content, as expected.

confirm

I am having the same issue as well as described by kylesmith in #4. Did anyone find out the issue and a potential solution? If yes, please share. That will be really helpful. Thanks!

I have had a similar issue - my [not great] solution:

1. create a [hidden] workflow status field (ended up going with a term reference) on whatever node you are triggering on
2. Add an action to the rules that fire on updates to add a term to the workflow status field (e.g. 'updated').
3. Added an 'and' filter to the rules that I want to prevent from double firing - specifically a NOT AND if the 'updated' term was present.

This makes my rules complicated in terms of their sequencing - but it got rid of my double/recursive firing issue - I could see this getting really messy if you have lots of concurrent rules going.

Yeah simple rule for me. If content of type is updated then duplicate emails sent.

I think the problem here is that recursion prevention just prevents the rule that triggered the node save to be triggered again - if you have another rule it will be triggered for both node saves. Rules cannot know whether you want to trigger the second rule for both saves or not.

So I'm not sure how this could be approached best, maybe some additional setting that tells rules to run a certain rule only once per rule evaluation? I guess it could be enabled by default.

Was this issue addressed in the latest release of Rules? I'm on 2.3 and am running into this problem.

Me too..

Hello,
Any news? I tried the suggestion of mapton1 in #10, but couldn't find a way to reset the taxonomy back for the next node update without getting the duplication again.
Thanks, Yael

Stupid (but working) workaround--

Add a custom PHP condition to your rule with something similar to the following:

global $prevention;
return !isset($prevention);

Add a custom PHP action to your rule with something similar to the following:

global $prevention;
$prevention = true;

This may not be best practice but I don't really think that using flags and hidden fields is necessarily a better practice, either.

Essentially, the action sets the $prevention variable that is accessible when called later by any recurrences of the rule's event yet it doesn't live in a database anywhere and it only lives as long as the current http request. Thus, you're not left wondering how to reset it after initially setting it to prevent the second iteration.

Done.

Thank you very much @DigitalFrontiersMedia, it worked great for me!

Agreed, what @DigitalFrontiersMedia suggested worked for me as well, thank you very much!

#16 removed duplicate emails for me also, thanks @DigitalFrontiersMedia for the simple and working solution.

#16 worked perfectly.

#16 worked perfectly for me, too, but only after some hours of frustration ....

You need to have the Core module PHP filter enabled otherwise you won't see the PHP section in Rules' drop-down lists.

I guess everyone but me knew that already, but if you get here and you can't make the excellent suggestion in #16 work, enable the PHP filter module and make sure you have permission to use custom PHP.

#16 did not work for me.
I am using rules to send out email to the author of the blog post when the comment on the blog post is published(approved by admin).

EDIT:

it started working for me today. May be a cache issue.

Thank You

This is something that needs to be included in Rules somehow. Thanks @DigitalFrontiersMedia!

#16 works for me, too. Thanks.

#16 thanks!

Below is a possible double email workaround without PHP. Apologies for being off topic from the thread.

In our case the double email was only happening when email was sent by the Rule itself. We also have rules scheduling components, these Components send mail, but those have never sent double mails. If we were to send emails by Component, then any doubling may be resolved. But it doesn't resolve this thread issue of Rules Recursion.

Example: When a Component is created it requires "A key to identify the e-mail sent." with a Value of [node:nid]-coordinator.

A Rule schedules the component. The component sends the mail at the scheduled date/time. Any recursion would simply overwrite the existing scheduled item with the same key, only sending one mail. The scheduled item could be short, +1 second. Cron is a consideration with this method which +1 second is not necessarily realistic, however you may find some methods to run Cron for this case.

Just to reiterate this only happens when using Node event "after updating existing content". When using Node event "after saving new content" then there is no issue, so sending an email by the rule itself is okay. These were the only events tested and resolved without PHP.

maybe follow here https://www.drupal.org/node/430274

Closed some related issues as duplicates.