Workflow run status Failed even if the last action Succeeded

Question

While it happens to be the result I actually want in my particular situation, it seems arbitrary. Can someone help me understand why in some cases a workflow run can fail even when the last action was successful? How should I rationalise this behaviour and is it documented somewhere?

A minimal example for demonstrative purposes:

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Compose": {
                "type": "Compose",
                "inputs": "@div(1,0)",
                "runAfter": {}
            },
            "Response_OK": {
                "type": "Response",
                "kind": "Http",
                "inputs": {
                    "statusCode": 200
                },
                "runAfter": {
                    "Compose": [
                        "SUCCEEDED"
                    ]
                }
            },
            "Response_Fail": {
                "type": "Response",
                "kind": "Http",
                "inputs": {
                    "statusCode": 200
                },
                "runAfter": {
                    "Compose": [
                        "FAILED"
                    ]
                }
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "triggers": {
            "When_a_HTTP_request_is_received": {
                "type": "Request",
                "kind": "Http"
            }
        }
    },
    "kind": "Stateful"
}

In this example the Compose action is designed to always fail and hence the Response_Fail action is executed last. The Response action obviously succeeds, but the workflow run is still reported as having failed. This is what I do not understand.

Let's do a slight modification and have a single Response action handle both cases.

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Compose": {
                "type": "Compose",
                "inputs": "@div(1,0)",
                "runAfter": {}
            },
            "Response_OK_or_Fail": {
                "type": "Response",
                "kind": "Http",
                "inputs": {
                    "statusCode": 200
                },
                "runAfter": {
                    "Compose": [
                        "SUCCEEDED",
                        "FAILED"
                    ]
                }
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "triggers": {
            "When_a_HTTP_request_is_received": {
                "type": "Request",
                "kind": "Http"
            }
        }
    },
    "kind": "Stateful"
}

Now the workflow run is reported as successful. Why do these workflows runs result in different statuses?

This is what the documentation states for Run status - Failed:

At least one action in the run failed. No subsequent actions in the workflow were set up to handle the failure.

Why isn't the Response action in my first example interpreted as having "handled the failure", whereas in the second example it is?

Answer 1

The "answer" in the comments looks like something generated by a language model and if you read through it, you can quickly see that it doesn't really address the question. It is a non-answer and factually incorrect (Response_Fail action handles the failure just fine).

However, this is the reasoning I have come up with my own research:

• Perhaps unintuitively to a person with a background in programming all the execution paths / branches (including leaf actions in the workflow) are still evaluated when determining the workflow run status in Azure Logic Apps - even though the actions themselves were not executed.
• For example, in the first scenario, the Response_OK action was not executed: status 'Skipped'. However, it is still considered when determining the run status. Furthermore, as said action was skipped, the status of the preceding action is examined instead. And since the status for that action (preceding Compose) was 'Failed', the entire branch is evaluated to having been failed.
• If any of the branches are evaluated as 'Failed', the entire workflow run is marked as failed.
• Therefore, the failed run is, unlike stated in the response in the comments, actually caused by the Response_OK action, not the Response_Fail action.

In the second scenario, there is only one branch and its last action is successful. Hence the run is marked as succeeded.

The behavior is further explained here in the documentation.