Automation Kicks off Twice | Issue Created Trigger

[Erica Robinson]

A team member reached out to me to advise that a previously working automation was getting triggered twice. I've looked over the automation and I'm not seeing any reason why it would kick off two times.

Automation in question:

Here's a snippet from the audit logs showing that there were no config changes between the last successful run (single run) vs the most recent run (duplicated):

I've reviewed all audit logs for the offending issue key and there was only a single automation that kicked off against it (expected). So I'm not sure if this is something that I need to make adjustments on the automation or something else.

[Bill Sheboy]

Hi @Erica Robinson 

Based on the audit log, the rule seems to be triggering itself.  Please check if this option is enabled in the rule details at the top:

Check to allow other rule actions to trigger this rule...

That option is disabled by default to prevent rule errors / accidental looping.  It should only be enabled when one intentionally wants the actions of a rule to trigger others. 

But for your rule, it is both triggered on issue create and creating new issues, and so certainly could cause racetrack errors.

Kind regards,
Bill

[Erica Robinson]

Hey Bill,

The "Check to allow other rule actions to trigger this rule" is enabled as the main ticket would only be created by a different automation that clones a ticket over. I did try to remove it entirely and it didn't kick off at all.

Thanks, 

Erica

[Bill Sheboy]

The log clearly showed the rule triggering itself, and you describe there is another rule creating the initial issue that triggers this rule.

So the big question is: how will this rule prevent itself from processing if you re-enable that "Allow rule trigger..." option?

The only way to do that is:

• After the issue created trigger, add the Re-fetch Issue action to slow the rule down a bit, reloading the trigger issue before proceeding
• Ensure the first rule conditions after the Re-fetch Issue can prevent the rule from continuing due to the issues it is creating.  For example...
  • The rule you currently show tests if the field FIELD NAME is not empty.
  • And so none of the issues created in this rule should set a value to FIELD NAME or the rule will loop until it halts all automation in your site.

[Erica Robinson]

I did confirm that the expected field isn't being set by any of the created tickets - although the field is available for use. I've added a Re-fetch Issue to the automation to help slow it down, but the results are the same. 

I looked in the Global Automation audit log to see if the most recently created item had more than one rule triggered against it, but it's just the original rule that creates the ticket + the duplicated rule:

[Bill Sheboy]

As written and with the "Check to allow other rule actions to trigger this rule..." option enabled, the rule will definitely trigger multiple times if the created issues are in the same scope as the rule.

The questions are: which issue is doing so and does it perform any unexpected processing?

For the two most recent executions (where you only expected one):

• expand the audit log details
• to the right of the "Issue Created" part of the log, there is an arrow to the right >
• expand those additional details
• note which issues triggered the rule; there should be two different ones
• for the unexpected trigger issue, investigate with the remainder of that log if the rule performed any unexpected processing steps

[Erica Robinson]

I would've expected two different issues to trigger the rule - seeing as it was triggered twice, but there's only one issue that triggered both:

[Bill Sheboy]

Thanks for that info!  And that is curious...

First, please remove the filter at the top on ADMIN-9266 and check the log again to observe how that changes what you see...particularly how many rule executions happened after first triggered by the creation of ADMIN-9266.  You may need to expand several executions to check which issues were involved.

Next, how was issue ADMIN-9266 created: by a person, by an automation rule, or by some other process / app?

[Erica Robinson]

Here's a snippet of the audit logs from immediately after the initial creation. From what I can see, nothing else ran between the two:

ADMIN-9266 is auto-generated from a user submitted ticket from a different project.

Here's the rule that generates this ticket: 

I did confirm that "Check to allow other rule actions to trigger this rule." is not enabled.

[Bill Sheboy]

I thought you wanted that option enabled so the other rule creating the issue will trigger this one?  Which is certainly okay; just gotta track down the problem.

Based on the logs, there is something causing the issue-created event to be fired at least twice for the same issue, leading to the rule starting multiple times.

I just checked the public backlog and I did not find this symptom for the Issue Created trigger (although it exists for other triggers).  However, Atlassian is actively rolling out a new retry capability which automagically attempts to correct temporary system problems with rule actions.  I wonder if there is an edge case for your rule set causing this result.

While this symptom is still happening, I recommend working with your Jira Site Admin to submit a ticket to Atlassian Support here, including a link to this community thread and to that announcement article.  They may see something with their internal logs that we are missing.  https://support.atlassian.com/contact/#/

When you hear back from them, please post what you learn to benefit the community.  Thanks!

[Erica Robinson]

Apologies I should clarify. The Clone ticket automation should not be triggered by another automation, but the Tasks ticket does need to be triggered via automation.

The Clone ticket automation is the initial one, which should only create a single ticket - that's working as expected. The Create Enablement Tasks is the one that needs to be triggered by the Clone automation.

As of right now, the initial step is working as expected (original ticket is cloned to a new project) but the second step doesn't work quite right anymore (create Tasks under the newly created clone ticket).

I'll get the ticket submitted to Atlassian Support and report back once I hear more. I appreciate you taking the time to look at this with me.

[Erica Robinson]

Hey Bill,

I wanted to follow up as I did receive a response from Atlassian Support. They've advised that this issue is being caused by a bug that monitors the "Parent" field.

Here's the bug ticket: https://jira.atlassian.com/browse/AUTO-1616

I did confirm that while the ticket current only specifies the "Field value changed" trigger it does seem to be affecting other triggers than the one identified in the ticket.

Thanks,

Erica

[Bill Sheboy]

Thanks for the follow-up, Erica!  I had forgotten about that defect, and...

That response from the support team is very troubling, and they should change the defect Summary and raise the Severity of impact.  Many rule writers likely assume the defect only happens for the Multiple Issue Event trigger or the Field Value Changed trigger with both create and update changes selected.

My hypothesis of why this is happening for those triggers is related to how automation rules use the REST API after the change from Epic Link to Parent:

• the create issue endpoint in the REST API supports setting the parent during create, however...
• it appears automation rules do not take advantage of that; instead they create the issue and then use a second call to update the issue for the parent

This does not explain why this would ever happen for the Issue Created trigger.  I will add a comment to that defect.

[Erica Robinson]

I appreciate the additional input. I had brought up a similar concern that while the results were the same the cause was not. This is the information they provided - although it still doesn't entirely align with the existing bug ticket:

While the bug mentions the 'Field Value Changed' trigger, we believe that the problematic behavior is due to the Parent field. As seen in the steps to reproduce below, the problem occurs when the 'create issue' operation is being called with Parent defined data:

I have added an internal comment to this bug asking that we either update the Summary or spin off a new bug, linking it to this existing one.

Hopefully we'll see some adjustments or updates. 

[Erica Robinson]

I wanted to keep this discussion updated. While support did indicate that the issue was related to the bug outlined above, it seemed off - as you noted Bill.

I rebuilt the automation that was originally kicking things off and I haven't seen any duplication of Tasks since it was rebuilt.

Original automation:

Rebuilt automation:

The new automation was built out to intake form data which the original did not need to have as it was just using the fields provided in the Request Type setup.

I don't have the "Action: Clone issue" any different than the original one; however the trigger here is different. I've tested submitting the request connected to this form and confirmed that the automation that kicks off the tasks is only getting triggered once instead of twice. So it's back to working as expected now!

[Mathew Lederman]

@Erica Robinson is it possible that you have two automation rules named the same? I've had it happen where somebody creates a copy when one rule isn't working, and then both rules start working simultaneously. 

[Erica Robinson]

Hey Mathew, 

I did confirm that there are no duplicate rules. Luckily there aren't many in the company that have the availability to create/manage rules and those that do tend to submit tickets for the modifications anyhow.

Thanks,

Erica

[Varsha Joshi]

Hi @Erica Robinson 

What do you see when you click on show more?

[Erica Robinson]

Hey Varsha, 

Here are those details:

Thanks,

Erica