Most Recent created issue key not found in automation

[Rai Warbasse]

Using Jira Version 8.22.1 project automation

The Setup:

A 'story' Issue contains a linked 'test' issue of "tested by"

When the test issue transitions to a fail, it triggers a transition on the story issue which triggers this automation flow.

When this automation flow is triggered, I create a 'defect' issue using a current issue branch and link the defect as blocking to the story.

I then have a second branch "for linked issues", to the story, which targets the test issue.

The Problem:

I am attempting to link the test issue to the defect issue by using the 'most recently created issue' from the 'link issues' action, but the issue key of the created defect issue can't be found; however, it is in the log output.

There are several articles similar to this but none of the solutions work.

LOG OUTPUT:

[Bill Sheboy · Accepted solution]

Hi @Rai Warbasse 

I believe you are seeing this defect/symptom where the {{createdIssue}} smart value is not visible to the scope outside of an if/else or branch in which the issue was created: https://jira.atlassian.com/browse/AUTO-154

Without seeing your entire automation rule, my suggestion would be to consider how you might restructure the rule so the create issue action is at the same scope where you need the {{createdIssue}} smart value.  Please post an image of your entire rule if you want ideas to help with that.

Kind regards,
Bill

[Rai Warbasse]

Thank you for that but it is contained with a single 'if' rule. Here is the whole view:

[Bill Sheboy]

I do not believe you need the For Current Issue branch as it is just nesting down from the trigger issue.  Instead you can just reference {{issue}} or {{triggerIssue}} as needed. 

Please try removing that branch to see if the {{createdIssue}} smart value becomes more visible to the branch below it.

[Rai Warbasse]

Bill, you are a savior. That was the issue. removing the initial branch fixed it.

[Bill Sheboy]

I am glad to learn that helped.

I find this symptom/defect curious as my understanding was that branches on one-and-only-one thing (e.g., branch to current issue) get converted to in-line code, as if the branch did not exist.  Compare that to branches which could be on more than one thing (e.g., linked issues, JQL, etc.) which get run in parallel and asynchronously, in separate processes.  I guess the "branch scoping" rules outweigh the in-line stuff for this symptom.

[Rafa]

Another work around is to define `{{createdIssue}}` at the top level, that will make its scope global. (as read somewhere in one of the multiple documentation pages, can't remember where).

So, you define  {{createdIssue}} = 0

and after creating the issue, the variable will have the new issue's details.

then, you may want to add somewhere "if  {{createdIssue}}  != 0 then..etc", to check the branch where the new issue was created was actually entered

[Bill Sheboy]

Hi @Rafa 

Have you tested this suggestion you propose?

I wonder about it:

• There is no concept of "global scope" in a rule; it is all about context within the rule structure
• The technique described looks like is overwriting a built-in smart value, but instead that actually creates a new one with a duplicate name.  There is no guidance on the expected behavior in that case as {{createdIssue}} is dynamically set during rule execution.  Certainly for issue fields, duplicate field / smart value names cause unpredictable behavior as to which will be used in the rule.
• Creating a variable before a branch, to preserve the value later when the variable is re-created, only works in one specialized case: where the branch can only be on one issue.  That is because such branches are converted to run in-line, as if they did not exist.  But as noted earlier, unless the variable is declared first, the branch scoping rules appear to take precedence.  All other branches run in parallel and asynchronously, and variables  / smart values set inside do not exist after the thread completes.
  • This specialized case would work for the original rule shown if a differently named variable as used, before and inside the branch.  For example, saving {{createdIssue.key}} as varKey.

Regardless, the simplest fix for the original rule was just to remove the branch on current issue, as the rule structure did not need it.

Kind regards,
Bill

[Rafa]

Hi @Bill Sheboy ,

yes it works, I use it on a couple automation rules. In one of them I use it to get the "Most Recent created issue key" to link it to others, but for "reasons", I need to do it outside of the branch where the issue gets created. So I store the key, and lower down the execution, I check the key of the issue created earlier. (see screenshot of 2 rules)

This was described by an "Atlassian Team" user in either an article or an answer (I can't remember or find where, since I've opened hundreds of tabs in the past weeks).

Regardless, the simplest fix for the original rule was just to remove the branch on current issue, as the rule structure did not need it.

Correct. Your answer solved the OP's issue by avoiding the problem to begin with. Whereas my answer gives a more general solution (or workaround) to the "Most Recent created issue key not found in automation" problem. Win-win : )

PS: Where do you get that branches are run "in parallel and asynchronously"? Rules doe run in parallel and async, but branches within an automation rule seem pretty sequential to me.
Maybe you thought I meant global variables across automation rules or executions of an automation rules? (I didn't)

[Bill Sheboy]

For this technique with one-and-only-one-thing branches, I recommend using a different variable name.  There is no documentation of the expected behavior when shadowing a built-in smart value name.

Regarding branch execution with could-be-more-than-one-thing, there have been several community posts from Atlassian team members on this.  And here is the reference in the documentation, although they do not use the technical terms to avoid confusing customers: https://support.atlassian.com/cloud-automation/docs/jira-automation-branches/#Ordering-of-branch-executions 

There is an open suggestion to add the ability to select sequential processing, or at least add a "wait until done" for branches as exists for the Send Web Request action.  Please look here to find that one: https://jira.atlassian.com/browse/AUTO-32

Regarding "global", I did think you meant within the scope of one rule.

[Rafa]

Hi

I recommend using a different variable name. There is no documentation of the expected behavior when shadowing a built-in smart value name.

Some "atlassian team" user suggested that particular use (I would not have thought of it myself). And it's the only way I can see to make "link most recently created issue" work.

Although it would not surprise me that their documentation and suggestions were not in sync..

Regarding branch execution...

Interesting. Dind't know that. Thanks for the link.