消耗型Azure Logic App部分场景Return步骤超时，原因何在？

我使用的是消耗型（Consumption）Azure Logic App。流程包含多个连接器，首个连接器为Azure Function，预期返回200 Ok及JSON响应。最后一步中，Logic App需返回包含前序JSON中某个值的202响应（并继续后台执行）。

目前发现Return步骤因超时报错，但将各连接器角落显示的耗时相加后，并未达到超时阈值。请问我忽略了哪些关键因素？

• 连接器队列与冷启动延迟：连接器角落统计的仅为自身执行耗时，但消耗型Logic App调用Azure Function时，可能遇到函数实例冷启动、资源队列等待的情况，这部分时间不会计入连接器执行耗时，但会算入流程总耗时。
• 流程引擎的隐性开销：Logic App调度流程、同步状态、处理数据转换/解析的系统耗时，不会显示在连接器的耗时统计中，复杂流程下这部分累积起来会占用不少时长。
• Return步骤的超时计算逻辑：消耗型Logic App的HTTP触发流程，超时是从请求发起至Return步骤开始执行的总时长，而非各连接器耗时之和。如果Return前的流程分支存在未优化的等待逻辑（比如未正确拆分异步执行），会导致Return启动过晚触发超时。
• 分支/循环的独立超时设置：若流程包含循环、条件分支，这些分支可能有独立的超时配置，其耗时会累加到总时长中，但不会体现在单个连接器的耗时统计里。
• 异步操作的等待陷阱：如果前序Azure Function或其他连接器采用异步模式，Logic App可能会默认等待异步操作完成才进入Return步骤，这部分等待时间不会被连接器统计捕获，但会占用总时长。

内容的提问来源于stack exchange，提问作者Rob Joosen