You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Azure Logic App循环中Send to Hub动作内存泄漏与重复事件问题咨询

问题分析与解决方案

核心原因

你遇到的不是内存泄漏,而是Azure Logic App变量的延迟绑定+全局作用域导致的竞态条件:

  • Logic App的变量是全局实例,所有循环迭代共享同一个变量对象
  • Send Event动作对变量的引用是延迟绑定——动作实际执行时才会读取变量的当前值,而不是在你设置变量时就固定快照值
  • 当For Each并发执行时,后序迭代会提前修改alert_formatted的值,还没执行的Send Event动作就会读取到被修改后的变量值,导致重复;加1秒延迟后,所有迭代的变量修改都已完成,所有Send Event最终都读取到最后一次的变量值,因此全重复

可行解决方案(无需降并发控成本)

  • 直接内嵌消息体生成逻辑:删掉alert_formatted变量,把原本用来生成该变量值的表达式直接写到Send Event的消息体输入框里。每个迭代会独立计算消息体,完全避免变量共享问题。
  • 用Compose动作做值快照:在设置alert_formatted变量后,立刻添加一个Compose动作,输入值设为@variables('alert_formatted'),然后Send Event引用这个Compose的输出。Compose会在执行时快照输入值,后续变量修改不会影响它的输出,这样每个迭代的消息体都是独立的快照,支持正常并发。
  • 批量发送优化(如果场景允许):如果你的消息可以批量提交,直接使用Event Hub的Send Batch Event动作,把For Each的目标集合作为批量输入,一次性发送所有消息,彻底避免循环内的竞态问题,同时提升执行效率。

补充说明

把For Each并发设为1确实能解决问题,但会牺牲执行效率并增加运行成本,上面的方案可以在保持并发的同时解决重复问题,更适合生产场景。

内容的提问来源于stack exchange,提问作者Jon

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.06.12 16:57:14