nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Transition action allows condition to pass if the the transition is done fast, but not if done slow

Stef Green

I have a rule (see image right below), it listens to whether current stories in my epic are transitioned to Done, and if all of them are done, it spawns some subtasks.

❗ THE PROBLEM:
If I transition its current tasks done within a few seconds of each other, it triggers this rule twice (which it shouldn't). But if I transition them i.e. with 10 seconds in-between, then it works fine and doesn't trigger this rule twice.

See rule here:

Moreover, I have another rule which is very identically structured, and that doesn't have the problem. Even if I buld edit all tasks to it as fast as possible, it doesn't trigger twice, see here the rule is basically identical:

I'm thinking either it's a bug or there's some weird little setting somewhere I'm forgetting, but I've now spend hours trying to really read everything single difference trough and can't find any.

Help would be hugely appreciated!

Accepted answers

Bill Sheboy

Hi @Stef Green

You are describing two different issues, so let's look at them separately: a timing problem and field-set on issue creation.

Timing problem

Your rule design will lead to multiple executions when there are multiple tasks in the epic. That seems to be what you intend. This will occur no matter how fast you transition issues as each issue's transition should trigger the rule as a new instance.
One challenge is a task's rule execution could still be in progress when another starts, causing collisions when checking multiple child issues of the epic's related issues condition.
One solution could be to set an indicator in the epic, which then triggers a separate rule for the epic's rule to create the new tasks. Once triggered, that new rule should disable the indicator and re-fetch the epic, slowing down and reducing the chance of it re-running in a short timeframe.

Field-set on issue creation

There are posts showing that field error can occur when a field: has workflow changes, is missing from a view, or when there are multiple instances of a custom field (often due to use of team-managed projects).
I suggest first fixing the timing problem, and then investigate this error

Best regards,

Bill

All comments

Dirk Ronsmans

Hi @Stef Green ,

On the rule details you normally have an option/checkbox "

Could you verify on the rule that is executing too much that this is checked or unchecked?

Stef Green

Thanks yes I can verify that it's not checked see image:

Stef Green

Note I also have this error in almost all my rules but all other rules seem to run fine even though it's there.
And I don't now how to fix it, when I search for it in fields it doesn't appear, as in nothing is called "Parent" there's just this parent link (see image)

Bill Sheboy

Hi @Stef Green

You are describing two different issues, so let's look at them separately: a timing problem and field-set on issue creation.

Timing problem

Your rule design will lead to multiple executions when there are multiple tasks in the epic. That seems to be what you intend. This will occur no matter how fast you transition issues as each issue's transition should trigger the rule as a new instance.
One challenge is a task's rule execution could still be in progress when another starts, causing collisions when checking multiple child issues of the epic's related issues condition.
One solution could be to set an indicator in the epic, which then triggers a separate rule for the epic's rule to create the new tasks. Once triggered, that new rule should disable the indicator and re-fetch the epic, slowing down and reducing the chance of it re-running in a short timeframe.

Field-set on issue creation

There are posts showing that field error can occur when a field: has workflow changes, is missing from a view, or when there are multiple instances of a custom field (often due to use of team-managed projects).
I suggest first fixing the timing problem, and then investigate this error

Best regards,

Bill

Stef Green

@Bill Sheboy thanks so much. Not sure that's what you suggested but at least that's what I got from it and it works. So I seperated the rule into two rules, one that listens for all subtasks being completed and then sets a custom field, and then another rule that just listens on this custom field being changed and is set to "True" on allowing other rules to trigger it.

Thanks a lot!

Bill Sheboy

Yup, that is what I was suggesting, and I am glad that worked.

Sorry my explanation was so long; I was trying to give you some context in case two rules didn't work and you needed to uncover "why".

__Bill

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation