引发 TaskCanceledException 时 Azure ServiceBus 队列不重试消息

Question

我有一个 Azure WebJob 函数，用于侦听 Azure ServiceBus 队列上的消息。通常，当我在代码中遇到异常时，消息会按照Azure WebJobs SDK documentation 被丢弃：

SDK 在 PeekLock 模式下接收消息，如果函数成功完成，则对该消息调用 Complete，如果函数失败，则调用 Abandon。如果函数运行时间超过 PeekLock 超时时间，锁会自动更新。

根据Azure ServiceBus documentation，这应该意味着消息再次可用，并将被重试：

如果应用程序由于某种原因无法处理消息，它可以对收到的消息调用 AbandonAsync 方法（而不是 CompleteAsync）。此方法使服务总线能够解锁消息并使其可被同一消费者或另一个竞争消费者再次接收。其次，存在与锁相关的超时，如果应用程序在锁超时到期之前未能处理消息（例如，如果应用程序崩溃），则服务总线会解锁消息并使其可以再次接收（本质上是默认执行 AbandonAsync 操作）。

上述行为是通常发生的情况，但我发现此规则有一个例外。如果我的代码特别抛出了TaskCanceledException，则消息没有按照应有的方式被放弃：

public void ProcessQueueMessage([ServiceBusTrigger("queue")] BrokeredMessage message, TextWriter log)
{
     throw new TaskCanceledException();
}

当通过 Web 作业运行此功能时，我看到错误消息打印为 day，但该消息被消耗，没有任何重试，也没有进入死信队列。如果我将上面的 TaskCanceledException 替换为 InvalidOperationException，则消息将被放弃并按原样重试（我已根据实际的 ServiceBus 队列对此进行了验证）。

我无法为这种行为找到任何解释。目前我将TaskCanceledException 包装在另一个异常中以解决此问题。

问题

我遇到的 Azure WebJobs SDK 是否存在错误？ TaskCanceledException在这方面是不是特别，还是其他类型的异常也有类似的行为？

---

我正在使用以下 NuGet 包：

• Microsoft.Azure.WebJobs 2.3.0
• Microsoft.Azure.WebJobs.ServiceBus 2.3.0

Answer 1

如果执行不成功，函数应该放弃消息。如果您说该消息没有被放弃并重试，即使它应该是（假设 MaxDeliveryCount 设置为大于 1 并且接收模式为 PeekLock），那么它可能是函数的问题，而不是Azure 服务总线。您可以通过运行控制台应用程序并执行相同的操作来验证这一点，检查消息在哪里完成并从队列中删除，或者仍然在队列中并可供使用。

此外，您似乎正在使用旧版本的 WebJobs（和 Azure 服务总线）。执行验证时，您需要使用旧版 Azure 服务总线客户端 (WindowsAzure.ServiceBus) 而不是新版 (Microsoft.Azure.ServiceBus)。