Parallel branches all read 'cancelled' before any actions are taken. New spurious behaviour.

[HydrogenUtility]

I have a flow with three parallel branches each executing a conditional. After all runs since this morning each branch shows a state of cancelled and the flow records as succeeded. This is spurious behaviour as there is no obvious reason for the flow to suddenly cancel all branches.

The conditionals all ask basically the same:

ie, does one variable contain the other. Both are strings, neither are null. I tested this by temporarily adding a fourth parallel branch which served only to print out all the pertinent variables. It worked as expected; variables are good and the original three remain in a state of cancelled.

This is new behaviour. This flow has been working as designed for weeks, notwithstanding daily updates. I've since checked every update and tested by rolling back and resubmitting the trigger data. There is no change.

I'm baffled by this one and would dearly love a bright idea!

 

[DamoBird365]

Hi @HydrogenUtility 

Looks like Modfile is empty/null hence the condition doesn't evaluate and it reports - no input?

If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.
Cheers,
Damien

P.S. take a look at my new blog here

[HydrogenUtility]

Thanks @DamoBird365 , That's what you'd think right? So I added a step right before the parallel branches to print out all the variables (email to my sandbox) which will be used below and they're all valid and have values:
 
 

Variable check: 

"projectPhase" = [HUB-p001_FEED] 
"modFileKeyFull" = PD001 
"keyword" = transmittal 
"timestamp" = 20210419-1617 
"fileKey" = PD001 
"subjectArray [0]" = [HUB-p001_FEED] 
"subjectArray [1]" = Transmittal 
"subjectArray [2]" = PD001

 
Additionally strange is that this is a sudden behaviour change after the weekend and there's no obvious changes which have occurred upstream...
Those changes which have been made were minor and have been successively rolled back for testing.
 
Any other clues?

[HydrogenUtility]

UPDATE:

I added a temporary parallel branch and added an exact copy of the conditional of one of the preexisting branches: Evaluate YES -->send email saying 'YES' and print out all the variables, or NO --> send email saying 'NO' and print out all the variables.

The branch ran and evaluated as 'YES' (expected) but the flow run details says cancelled:

Further... I note that the original trigger on Monday 1400 AEST actually did partially complete! But not all the actions following the conditional executed!

This must be a bug right?

 

[DamoBird365]

@HydrogenUtility 

I am happy for others to come in on this one.  I thought I had the obvious but you've got that one covered.  A bug possibly but surely Microsoft have got this one covered 🙂  ?  Next step is re-creating all of the branches for those conditions?  April is bringing changes to CDS-> Dataverse Connectors, could one of these changes interfered with your Cloud Flow?  https://flow.microsoft.com/en-us/blog/announcing-changes-to-power-automates-native-integration-with-...

Damien

[HydrogenUtility]

Thanks @DamoBird365, the #1 clue for me is that this new behaviour started after the weekend without any other tinkering.

The triggers for this flow are mission critical emails and they occur every few hours. I'm watching each one and they are 'succeeding' according to the flow report but in fact the results are the same.

There are a bunch of steps above the parallel branches, many of which have their own conclusions like terminate with 'success' and / or send email and / or run child flow. These are all working as per normal so not every trigger gets as far as the branching line.

Here's another clue for you:

 

This condition is indeed true. The flow is 'thinking' about it. Long after the flow reports success. This is typical and in this instance the 'thinking about it' symbol stayed put until I closed the window.

I've added steps at critical stages along the flow which report variables (they're numerous and they are complex with string manipulations and array manipulations) by sending emails to my sandbox. I'll spend some time correlating output with each particular outcome and see if I can track done more clues.

Thanks for applying some brain power to it @DamoBird365 !

[DamoBird365]

Hi @HydrogenUtility 

If you've got access to MS Support through your admin portal, I would be raising a call with MS.  Get them to scratch their heads on this one.  Looks like some funny business on your tenant.  You could try re-creating the flow actions that are failing (or still running and marked as complete?!?) and see if it comes good but you will probably want peace of mind and a reason why and the MS Support Channels might identify if this is happening anywhere else.  

Damien

[HydrogenUtility · Accepted solution]

Cause of this was discovered with the assistance of Microsoft Support. Thanks @DamoBird365  for your efforts. See below excerpt from dialogue with Support Team:

 

And my response:

"There were three terminate actions below the parallel branch, ie inside one of the branches. I removed these and the flow works as per normal.

However, this means that code in the branches is executing asynchronously. Further is can be demonstrated that these termination actions were executing even though the condition which would activate them evaluates to FALSE."

I've updated my workflow to acknowledge this behaviour with Power Automate. From a Javascript point of view I can see why this happens (there is no actual parallel branching occurring) but why the terminate action executed in the first place remains a mystery.

Note to others who might encounter the same issue: I added terminate steps whenever I wanted the flow to 'wrap up' neatly. It seems this is out of step with the developer's intended usage. It is of minor concern to me so I have omitted these terminate steps throughout allowing the inbuilt rationale to alert me to succeeded, failed, or cancelled states.

 

 

[huddjw541]

Any update from MS on why Terminate action executes regardless of condition? Is happening with a new flow of mine.
this means that code in the branches is executing asynchronously. Further is can be demonstrated that these termination actions were executing even though the condition which would activate them evaluates to FALSE.

TY

[huddjw541]

The very curious thing was that I have a terminate statement that (I'm assuming- haven't heard otherwise from users...) still works in a workflow that I released in 3/2021.
I remember that I had added it, as w/o it, it was infinitely looping.