Logic App获取Service Bus队列消息未达最大计数的问题咨询

Get messages from a queue (peek-lock)操作里配置的最大消息计数是单次调用可返回的消息数量上限，不是服务端必须凑够返回的承诺值，仅返回1条通常由以下原因导致：

• 底层Service Bus接收API的设计逻辑：该操作底层仅发起1次批量接收调用，服务端不会为了凑够设置的数值阻塞等待消息攒批，只会返回调用瞬间处于活跃可接收状态、且在传输缓冲区中可立即取用的消息。哪怕队列总存储消息量远大于170，只要调用当下满足返回条件的消息只有1条，返回结果就只会有1条。
• 响应大小硬限制：Service Bus对单次批量接收的响应包总大小有明确阈值，标准层单次响应最大256KB，高级层最大1MB。如果队列里的单条消息体积已经接近这个阈值，单次调用自然只能返回1条，避免超出包大小限制。
• Peek-lock锁配额占用：Peek-lock模式下每拉取一条消息都会给对应消息加临时独占锁，锁会占用命名空间/队列级别的并发接收配额。如果当前队列已经有其他消费者（其他Logic App实例、自行开发的消息处理程序、Azure Function等）持有了大量未释放的消息锁，剩余可用配额不足时，本次调用能获取到的消息数会远低于设置的上限。
• 消息状态不可见：队列中其余消息如果处于计划投递未到激活时间、消费失败进入延迟重试状态、已被其他接收端锁定未释放、已转入死信队列的状态，对本次peek-lock调用是不可见的，无法被拉取到。
• 连接器无自动凑批逻辑：Logic App内置的Service Bus连接器不会在单次调用返回消息数不足时自动循环拉取补量，仅执行一次调用就返回对应结果，不会自动重试凑够设置的170条。

如果需要稳定拉取到指定数量的消息，可以在该操作后添加Until循环，判断累计拉取的消息数是否达到目标值，未达到时循环调用peek-lock操作累加结果即可，注意设置合理的循环间隔避免触发服务限流。

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