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; } } }

Jira Automation main rule flow does not "wait for response" for web request in If-branch

Johnny FromCanada

In a Jira Automation rule, when a web request is sent from the main rule flow, it will indeed "Wait for response" as expected.

But, when a web request is sent from within an If-block flow, even if "Wait for response" is enabled, the main rule flow resumes execution immediately in parallel with the If-block flow, creating a race condition between the two flows (hence wreaking havoc on the desired logic).

AFAIK, If-blocks (unlike Branch components) are not supposed to fork flow control nor return flow control early, i.e., before the If-block completes execution.

Anyone else experience this and/or know what is going on? Is this a bug or a "feature"?

My scenario: Two web requests - the second depending on the success of the first. I check the success of the first response using an If-block, and make the second web request in the If-block. But the logic after the If-block races ahead and gets interleaved (randomly?) with the remaining logic within the If-block.

Comments

Mykenna Cepek

Sounds like a bug to me. I'd report it (here). Be sure to give Atlassian access to your instance, and give them the name of the rule which illustrates this problem.

Ideally this will be a rule they can execute in your environment to reproduce the problem you're reporting. So if you need to copy your rule to make a "safe" version that they can run and not affect any active projects, for example, consider doing that. And verify that it still demonstrates the problem.

Also, if your initial report (a PCS-12345 ticket) evolves into a Bug or Suggestion in the JAC, then please post it here so that others can vote for it.

Bill Sheboy

Hi @Johnny FromCanada

Would you please post an image of your rule structure (no need for the web request details) to clarify a bit? It is unclear from what you are describing by "if-branch" and "if-block": is this a single condition or an if/else component. So the scoping of the symptom you describe may be a factor. Thanks!

Regarding branches, when the branch can evaluate to one-and-only-one issue (e.g. For Parent) those get in-lined and and so run synchronously. The multiple issues ones (e.g. on JQL) are the ones which run asynchronously...according to the documentation.

Kind regards,
Bill

Johnny FromCanada

K, I have added screenshots of a base-case rule and audit log. I have also edited the text to replace the confusing "If-branch" terminology with "If-block".

The action after the If-block runs before the remaining actions within the If-block (after the second web request).

This behaviour is highly reproduceable. It does not matter whether the web request succeeds or fails. It does not appear to be an anomaly of the logger (say being asynchronous), since any kind of action gets out of order (not just log actions).

My guess is that the web request fires, spawns a new thread (to wait for the web response), and yields to the main thread, which continues executing (after the If-block).

Mykenna Cepek

Thanks for posting more details. As @Bill Sheboy aptly points out, there are known inlining and asynchronous behaviors that can affect rule execution, and differ from our expectations. These effects are not well documented, but folks like Bill and I have called them out in many community postings.

An alternative approach for your rule would be to terminate the rule if the first web request fails, and let the rule proceed (at the main line, not within a conditional) to perform the second web request. To do this, use a conditional which only continues on with the rule if the web request succeeds.

I realize it's not as flexible, but it might get the job done.

Bill Sheboy

Thanks for that additional information, @Johnny FromCanada

In my experience, even the writes to the audit log do not consistently appear in the order of writing, so they cannot be relied upon for diagnostics of flow.

As you show your rule using the "wait for response", something seems odd. If you are on a paid license, I suggest working with your site admin to submit a support ticket to Atlassian here: https://support.atlassian.com/contact/#/

They have access to logs we do not, and may be able to uncover what is happening in the flow. When you hear back, post what you learn here to help the community. Thanks!

wojciech_kluszczynski

@Mykenna Cepek Could you share more details about the alternative approach? I'm facing the same issue as @Johnny FromCanada and looking for a solution. Thanks!

Mykenna Cepek

@wojciech_kluszczynski - here is an example of the alternate approach I suggest:

Screen Shot 2021-12-28 at 9.50.12 AM.png

Do not use the "if" component which branches. As @Bill Sheboy noted, branches sometimes execute in parallel (for performance reasons).

By using the "if" component which is in-line instead, things execute in order.

However, I don't actually think it is necessary to check the webResponse.status at all. Note the following configuration available on each "Send web request" component:

Screen Shot 2021-12-28 at 9.50.43 AM.png

In this use case, you would always check the first box, and always leave the second box unchecked. This will ensure that a failed web request will terminate the rule at that point. No additional "if" components are needed.

Curiously, this is also the simplest way to write this rule.

Welcome!

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

Quick Links

Find more posts tagged with

automation