Azure Function FixedDelayRetry致函数锁死无法处理后续消息

• 测试Azure Functions FixedDelayRetry 机制时出现执行阻塞：函数执行失败触发重试逻辑后，不会拉取处理下一条队列消息
• 阻塞解除条件：当前失败消息耗尽所有配置的重试次数、最终进入死信队列（dead-letter queue）后，函数才会恢复处理后续消息
• 验证环境：.NET Core 3.1、Azure Functions SDK 3.0，以下最小代码可稳定复现问题

[FunctionName("Function1")]
[FixedDelayRetry(5, "00:01:00")]
public void Run(
    [ServiceBusTrigger("SomeTopic", "SomeSubscription", Connection = "ServiceBusConnectionString")] string item,
    ExecutionContext context,
    ILogger log
)
{
    log.LogInformation($"Function executed at: {DateTime.Now}");
    throw new System.Exception("Error Happened!!");
}

• FixedDelayRetry 是Azure Functions运行时实现的进程内内存级重试策略，所有重试动作都在单次函数调用的生命周期内完成，重试间隔期间不会将消息释放回Service Broker
• 重试等待阶段，运行时会自动续期当前消息的Service Bus peek-lock锁，消息始终被当前函数处理实例占用，不会被其他实例拉取
• Azure Functions 3.x版本的Service Bus触发器默认maxConcurrentCalls（单实例最大并发处理消息数）配置为1，单条消息占用唯一的处理槽位后，没有多余资源拉取新消息，直接表现为完全阻塞。

• 调整触发器并发配置：修改host.json中Service Bus扩展的maxConcurrentCalls参数，预留足够的并发槽位处理其他消息，配置参考：

{
  "extensions": {
    "serviceBus": {
      "maxConcurrentCalls": 8,
      "autoRenewTimeout": "00:10:00"
    }
  }
}

注意：该方案仅能降低阻塞影响，被重试的消息依然会占用一个并发槽位，无法完全消除单消息对单槽位的占用

• 替换重试实现：弃用Functions内置的FixedDelayRetry策略，直接使用Service Bus原生的服务端投递重试能力。函数执行抛出异常后，运行时会立即释放消息锁，消息回到队列等待下一次投递，不会长期占用函数处理槽位，重试次数、重试间隔由Service Bus订阅/队列的属性配置，重试次数耗尽后消息自动进入死信队列。

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