Run After Action Timeout counts as Failure?

[MWilliams86]

Hello, 

So I've recently put together a flow that has a timeout catch parrallel branch if the proceeding action times out / doesn't receive a response. 

This parrallel branch is doing it's job and runs fine, but the flow gets marked as Failed because the previous actionable piece of the flow timed out. 

I don't think a flow has failed if a proper Run After Action has timed out parrallel branch properly executes. 

Is this a bug?

[v-micsh-msft]

Hi @MWilliams86,

I think the Run After is built for error handling, have you checked the following blog?

Error handling steps

Basically I think if the action (more action settings ) is not correctly performed within the time range, then it should be considered as fail.

If you have any concerns or better idea, then please consider submit it as a new idea.

Regards,

Michael

[noearcmon]

Well I guess if the error is handled then it should not be marked as fail. I have a flow that sends and item to approval. I configured the approval settings timeout to PT6H to wait 6 hours until timeout. If no response is received from the user in those 6 hours then I would take the decision of reject it automatically using a "run after" Action. But it is marked as fail despite I want this as the desired behavior. I do this because I don't want the flow to be running there for days and days waiting for a response from the user.

[mpoppe]

I noticed that the action fails if the timeout >= 1 hour.  If you specify it as for example PT10M, then the action succeeds.  So for me, this is a bug.  

[mpoppe]

In my case the problem is solved (so no bug after all)

I was using Do Until to perform the action. I overlooked the limits in do until, which are by default :

Count : 60

Timeout: PT1H

I changed this to

Count: 60

Timeout: P30D

No my flow works as expected.

[kalyanc]

@MWilliams86 @noearcmon @v-micsh-msft 

Certainly a design bug! The timeout was handled, so the flow should not fail. Failure of the flow should be considered based on the failure of a step in the flow, and not just the occurrence of timeout. 

Oddly though this behavior doesn't occur when a terminate command is used (which I ended up using as a workaround)