Why does Jira automation not apply to all issues returned from a JQL?

[keerthi]

I have set up an automation to update the fixVersion of issues after a release. This rule is triggered by another rule which ends with creating a new fixVersion.

Although the JQL for updating the fixVersion only returns less than 500 issues, I still find up to 50 issues that did not get updated with the new fixVersion.

I have tried to compensate for this by trying the same  action a second time. This reduced the number of issues that were missed, but I still end up with 20 or so issues that are still stuck on the old fixVersion.

[Samuel Gatica _ServiceRocket_]

Hi @keerthi 

Please uncheck the option "Only include issues that have changed since the last time this rule executed" as detailed in doc Automation rule is not executing the action on a request although the request is listed as part the JQL mentioned in trigger action. 

Best Regards

Sam

[keerthi]

Hi Sam,

Thank you for the suggestion. But I missed out on mentioning that I already had it unchecked and am still running into the issue

[Samuel Gatica _ServiceRocket_]

Hi @keerthi 

You may be hitting a service limit

https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

Best Regards

Sam

[Bill Sheboy]

Hi @keerthi 

Please check the audit log for your rule, as it is possible a rule like this could be running into one (or more) of the service limits for automation rules:

https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

Kind regards,
Bill

[keerthi]

Hi Bill,

Thank you for the suggestion. I checked the audit log and there were no errors.

I read up on the service limits as well and I'm confident we aren't hitting any of them. For context, we have less than 10 rules set up on the project.

[Bill Sheboy]

Interesting...

By the way: using that branch twice in the rule should not help...I would expect it to worsen the symptom you describe.  The reason is that branches on one-and-only-one issue (e.g. branch to parent, current issue, etc.) get run in-line and so they complete before the rule proceeds with the next step. 

But branches that could be on more than one issue (e.g. JQL, linked issues, etc.) get run asynchronously and in parallel.  There is no guarantee they will finish before the next rule step.  And so your issues in those two branches are possibly trying to update the same issues repeatedly.

Back to your scenario: let's try this test rule in the same place where your rule exists:

• trigger: version created
• action: lookup issues with your JQL from the rule
• action: write to the audit log {{lookupIssues.size|0}}

Now check if that contains the number of issues you expect.  If not, there is potentially an issue with your rule scoping or the JQL.

[keerthi]

Will try this out. Thanks

[keerthi]

Hi @Bill Sheboy ,

The number of issues that were written in the audit log turned out to be 100 which is way lesser than expected. I expected 308 issues.

I also eliminated the second branch for testing and noticed that 80 issues were left out. Which means 200+ issues got updated which is greater than the number returned from lookup.

Does lookup issues have some sort of limit?

[keerthi]

Looks like the lookup issues function has a limit of 100 unfortunately

[Bill Sheboy]

Thanks, @keerthi for that information.  I knew about that limit and wanted to check if it matched at least what you expected.

As I noted with the link about service limits, a branch can handle more than 100 issues but you could be running into a processing time limit.  At this point I suggest you have two options:

1. Keep your original rule and contact Atlassian Support to see if they can determine why the rule is not running through all issues.  As the site admin of a paid license you may do that here: https://support.atlassian.com/contact/#/
2. Let assume you have only one, unreleased version at at time...Change your rule to use a scheduled trigger and JQL which identifies all issues to assign to the Next Unreleased Version.  Running the rule on a schedule will run repeatedly until all of the issues are be processed...and then it will stop triggering.

[Josh Costella]

Hi @keerthi

Did the 20 or so leftover tickets have anything in common? Did they all have more than one Fix version associated with them, perhaps?

If I was to troubleshoot this, I would start by looking at those 20 tickets in the JQL search list view. I'd have the status, labels, and fix version columns visible.

I'd want to start here just to confirm there wasn't a discrepancy between my JQL criteria and what tickets are being returned.

[keerthi]

That's a great suggestion Josh. Thanks for that.

I will check the next time the rule runs. It might be a week or so until I check. Will give an update then.

[keerthi]

Hi Josh,

The automation was run today and 24 issues did not get updated. I took a look at the properties but to see if they matched the JQL criteria and they do. They didn't have multiple fixVersions either.

The only common thing I could spot was that they were all created back in 2021.

I'm a bit lost as to why this isn't working as expected.

[Josh Costella]

@keerthi Interesting. Are you able to share what the audit log entry says for the most recent run?

[keerthi]

Does that give all the information?

[Josh Costella]

What is the scope of the automation? Is it limited to a single Jira project? 

[keerthi]

yes it is limited to a single project