如何限制标准逻辑应用内置Service Bus队列触发器的最大消息数？

主问题解答：是否可限制内置「当队列中有消息可用（peek-lock）」触发器的最大消息数？ #

目前没有官方支持的配置方式（包括local.settings.json）来限制该内置触发器的拉取消息数。该触发器默认会一次性拉取最多1000条消息，且未暴露可调整的参数，查阅应用设置相关文档也无对应配置项。

附加问题解答：限定条件下的批量消息处理替代方案 #

除了改用Recurrence触发器配合「Get messages from a queue」动作外，可采用以下符合限制条件的方案：

1. 开启Split On拆分消息，单条独立处理 #

• 开启触发器的Split On设置后，批量拉取的1000条消息会被拆分为独立的工作流实例，每个实例仅处理一条消息。单条消息的处理时长会远低于5分钟的锁定超时阈值，从根本上避免批量处理超时导致的死信问题。
• 注意：需确保逻辑应用的并行度配额足够支撑当前消息量的并行处理需求。

2. 调整Service Bus队列的重试阈值（辅助缓解） #

• 在队列的最大锁定时长已设为5分钟的前提下，可提高队列的最大投递次数（默认3次），延长消息进入死信队列的周期，为处理流程争取更多重试机会。
• 此方法为辅助手段，需配合其他核心处理方案使用，无法彻底解决超时问题。

3. 嵌套逻辑应用实现分批次处理 #

• 保留原「当队列中有消息可用（peek-lock）」触发器，主工作流接收到批量消息后，通过循环逻辑将消息拆分为小批次（如每50条一批），调用嵌套逻辑应用进行处理。
• 嵌套逻辑应用使用内置Service Bus连接器维持peek-lock机制，每批次消息的处理时长控制在5分钟内，既保留了原触发器的触发逻辑，又确保了消息处理的可靠性，同时流量完全在VNet内流转。

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