Logic App读取Service Bus消息时循环提前终止问题咨询

结合你的场景，我来梳理几个实际工作中常见的原因，都是踩过的坑：

• Peek操作的默认批量上限在作祟
  Service Bus的Peek（窥视）操作默认的MaxMessageCount参数是20——说白了就是每次调用最多只能拉取20条消息。如果你的循环逻辑里，每次调用Peek后只处理这20条，还没设置FromSequenceNumber参数指定下一次从哪条消息开始读，那下一次Peek还是会返回一模一样的前20条。就算你设置了30秒超时退出，可能30秒内刚好把这20条处理完，循环就直接停了，队列里剩下的消息根本没机会被读取。

• 会话队列的预取机制限制
  因为你是按SessionId读取会话队列，Service Bus的会话客户端默认有预取消息的机制，预取数量通常就是20条。这时候Logic App的连接器可能只能先拿到预取缓存里的这些消息，后续的消息需要触发新的预取操作，但如果你的循环逻辑没做这个触发（比如没释放会话连接再重新获取），就会一直读不到剩下的消息，直到30秒超时退出。

• 循环迭代耗时刚好卡到超时阈值
  要是你每次循环迭代只读取并处理一条消息，那每条消息的处理时间加上循环的间隔时间，累计到20条时刚好凑够30秒的超时上限，循环就直接退出了。比如每条消息处理1.2秒，加上0.3秒的循环间隔，20条刚好30秒，完美卡到超时点，剩下的消息自然没机会处理。

• 旧版连接器的硬性限制
  有些旧版本的Logic App Service Bus连接器，对单次Peek操作返回的消息数量有硬性限制（就是20条），而且没提供分页或者续读的选项。如果你的连接器版本比较老，大概率就是这个问题。

给你几个针对性的解决思路：

1. 调整Peek操作的MaxMessageCount参数，把它设成更大的值（比如100，只要不超过Service Bus的单批限制），这样每次能拉取更多消息；
2. 每次处理完一批消息后，记录最后一条消息的SequenceNumber，下一次Peek时把FromSequenceNumber设为这个值+1，确保读取后续的新消息；
3. 如果是会话队列，尝试调整预取数量，或者在每次读取后重置会话连接；
4. 适当延长Until循环的超时时间，或者优化单条消息的处理逻辑，减少每次迭代的耗时。

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