Azure Logic Apps测试失败HTTP操作无法添加输出参数如何解决

测试Azure Logic Apps工作流时触发提示For unsuccessful actions, there should not be outputs：通过设计器内置测试功能模拟HTTP动作、将动作状态选为Failure时，无法手动添加Output参数；但绕过测试流程直接发起真实请求时，可以正常看到失败动作返回的Status code、Body、Headers等输出内容，需要在后续操作中基于Status code做逻辑判断。
相关截图：


原工作流配置如下：

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
      "Bad": {
        "inputs": {
          "body": "Bad: @{outputs('HTTP')['statusCode']}",
          "statusCode": 503
        },
        "kind": "http",
        "runAfter": {
          "HTTP": [
            "TIMEDOUT",
            "FAILED"
          ]
        },
        "type": "Response"
      },
      "HTTP": {
        "inputs": {
          "method": "GET",
          "uri": "@{appsetting('externalServiceUrl')}/api/entities/"
        },
        "runAfter": {},
        "type": "Http"
      },
      "Success": {
        "inputs": {
          "body": "Success",
          "statusCode": 200
        },
        "kind": "http",
        "runAfter": {
          "HTTP": [
            "Succeeded"
          ]
        },
        "type": "Response"
      }
    },
    "contentVersion": "1.0.0.0",
    "outputs": {},
    "triggers": {
      "manual": {
        "inputs": {},
        "kind": "Http",
        "type": "Request"
      }
    }
  },
  "kind": "Stateful"
}

这个提示是Logic Apps设计器测试功能的硬限制，和工作流配置本身无关：

• 用设计器自带的「手动指定动作运行状态」功能做模拟时，只要把状态设为Failed、TimedOut这类非成功值，输出配置框会直接锁死，不允许手动填充失败场景的输出参数，这是测试工具自带的校验逻辑，不是工作流运行时的规则。
• 真实运行工作流时不存在这个限制：HTTP动作哪怕返回4xx/5xx错误、被平台标记为失败状态，只要请求成功拿到服务端响应，平台会自动填充statusCode、headers、body等完整输出字段，后续动作可以正常读取这些值，这也是直接发请求能看到失败动作完整输出的原因。

选以下任意一种方式即可完成该场景的测试：

• 使用静态结果功能模拟失败输出（推荐）
  静态结果是Logic Apps原生提供的动作模拟能力，不受测试面板的校验规则限制：
  1. 打开工作流设计器，选中需要模拟的HTTP动作
  2. 找到动作配置里的「静态结果」选项并开启
  3. 在静态结果配置页，将动作状态设为Failed，在输出栏手动填入需要模拟的statusCode、headers、body等字段内容
  4. 保存配置后运行测试，后续Bad分支动作可以正常读取outputs('HTTP')['statusCode']值，不会触发报错。
• 直接发起真实请求测试
  跳过设计器的手动状态模拟功能，走真实运行流程验证：
  1. 复制手动触发器的完整调用URL
  2. 将配置里的externalServiceUrl指向一个会返回目标错误状态码的测试接口
  3. 用Postman、curl等工具直接向触发器URL发起请求，运行时HTTP动作失败后会自动携带完整输出，后续分支逻辑会正常执行，可以在运行历史中查看状态码取值和分支执行结果。
• 临时调整分支触发条件验证逻辑
  如果仅需验证后续动作对statusCode的处理逻辑是否正确，可以临时修改配置快速验证：
  1. 给Bad动作的runAfter触发条件临时加上Succeeded规则
  2. 测试时将HTTP动作状态选为Succeeded，手动填入带目标statusCode的输出，验证后续逻辑的处理结果是否符合预期
  3. 验证完成后把runAfter条件改回原来的TIMEDOUT, FAILED即可。

内容的提问来源于stack exchange，提问作者Andrii Dovhal