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.

[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.

[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. 

[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:

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:

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.

[Johnny FromCanada]

Indeed, I ended up just assuming the web requests succeed a great majority of the time, i.e., coded for the happy path.  The unhappy paths flow through same basic path, but end up as a no-op.

Jira Automation does not accommodate much logical complexity in general, and I find myself constantly pushing against the envelope.  Hopefully it continues to improve over time.

[wojciech_kluszczynski]

Thanks for answers, in my situation I'm sending the POST to google sheet api to copy the file and later I'm sending another request to modify that file. In like 2% of the automations the call to google api is timing out. I'm looking for some kind of retry mechanism but for now what I see it is not  possible. 

[Mykenna Cepek]

I see. Well, you could try something like this then:

• Send web request to copy file (box 2 unchecked)
• Send web request #1 to edit file (box 2 checked)
• Continue only IF webResponse.status != 200 (inline, not branch)
• Send web request #2 to edit file (box 2 checked)

"Box 2" refers to the second checkbox for "continue running ... on non-200 response".

This might get you to 99.94% success rate. Add a third web edit retry to get to one failure every 125,000 attempts (estimated).

[Johnny FromCanada]

General looping is not available (beyond issue enumeration).  You could try recursion via a web request from your rule (or the repeatable part) to itself.

[Charlie Misonne]

Hi Johnny,

Did you file a bug report for this?

I'm hitting the same issue in an "for epic" branch.

The workaround will not work in my case.

[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).

[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!