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

Question

我有一个Azure WebJob函数，用于侦听Azure ServiceBus队列上的消息。通常，当我在代码中遇到异常时，会根据Azure WebJobs SDK文档放弃该消息：

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

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

如果应用程序由于某种原因无法处理消息，它可以对收到的消息调用放弃异步方法（而不是CompleteAsync）。此方法使服务总线能够解锁消息，并使其可供同一消费者或另一竞争消费者再次接收。其次，有一个与锁相关的超时，如果应用程序在锁超时过期之前无法处理消息（例如，如果应用程序崩溃），那么服务总线将解锁消息并使其可再次接收（默认情况下基本上执行放弃异步操作）。

上面描述的行为是通常会发生的，但是我发现了这个规则的一个例外。如果我的代码特别抛出了一个Task取消异常，消息不会像它应该的那样被放弃：

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

当通过web作业运行此函数时，我看到错误消息以day格式清晰地打印出来，但是消息会被消耗掉，不会重试，也不会进入死信队列。如果我将上面的TaskCanceledException替换为invalidooperationexception，则消息将被保留并按其应该的方式重试（我已根据实际的ServiceBus队列对此进行了验证）。

对于这种行为，我一直找不到任何解释。目前，我在另一个异常中包装了Task取消异常来解决这个问题。

我遇到的是Azure WebJobs SDK中的错误吗？TaskCanceledException在这方面是否特别，或者其他类型的异常是否具有类似的行为？

我正在使用以下Nuget软件包：

• 微软。蔚蓝色的WebJobs 2.3.0

Answer 1

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

此外，看起来你正在使用旧版本的WebJobs（和Azure服务总线）。执行验证时，需要使用旧的Azure服务总线客户端（WindowsAzure。ServiceBus）而不是新的（Microsoft.天青。ServiceBus）。