“排队” Azure事件网格Blob触发事件消息存储在哪里，如何清除它们？

Question

请原谅，如果我的用语有点不对劲；我是新来的。

我创建了一个Azure事件网格订阅，每当我将文件上传到Blob存储时，该订阅都会触发一个事件。我有一个响应此事件的Azure函数。我已经完成了所有这些工作，但是从先前的（错误的）上传中遗留了一些消息，这些消息周期性地失败（从关联的Azure功能的Azure门户的“日志”窗口中查看）。就像它们存储在队列中的某个位置并定期重试一样，尽管我不确定这是否起作用。

无论如何，我想做的是清除所有传输中或排队的事件，但我不知道在哪里可以找到它们来执行此操作。据我所知，它们只是在以太中漂浮。

我如何清除这些事件，以使它们不会继续随机触发我的Azure函数？

Answer 1

如果尝试进行传递时返回了200或202（确定/已接受）以外的任何其他值，则Event Grid将自动重试传递消息。默认情况下，它将重试24小时，并且使用指数备份，这会在每次请求之间增加额外的时间，直到它放弃为止。您将看到该默认进程正在运行。 （您还可以使用存储帐户配置死信处理，以便在未发送的消息最终失败时将其存储在某处）。

您可能需要的是创建订阅时可以创建的重试策略。可以肯定的是，您可以将最大传递尝试次数设置为1，这样它就不会重试（并且如果没有打开死信支持，则该消息将被丢弃）。有关更多详细信息，请访问https://docs.microsoft.com/en-us/azure/event-grid/manage-event-delivery#set-retry-policy

在没有该重试策略的情况下，我不知道有什么方法可以使已提交的邮件“出队”-您可能必须删除并重新创建对该事件网格主题的订阅。

Answer 2

除了@JoshCarlisle的答案外，对Event Grid message delivery and retry文档也更清楚：

使用死字法可以在重试策略逻辑中使用特殊情况。 如果死信是开启并且订户失败并出现 HttpStatusCode.BadRequest ，则事件网格将停止重试过程，并将事件发送到死信端点。此错误代码表示传递将永远不会成功。

以下代码段显示了死信消息中的一些属性：

"deadLetterReason": "UndeliverableDueToHttpBadRequest",
"deliveryAttempts": 1,
"lastDeliveryOutcome": "BadRequest",
"lastHttpStatusCode": 400,

以下列表显示了一些状态代码，事件网格将在重试过程中继续这些状态代码：

HttpStatusCode.ServiceUnavailable
HttpStatusCode.InternalServerError
HttpStatusCode.RequestTimeout
HttpStatusCode.NotFound
HttpStatusCode.Conflict
HttpStatusCode.Forbidden
HttpStatusCode.Unauthorized
HttpStatusCode.NotImplemented
HttpStatusCode.Gone

一些死信属性的示例，当 HttpStatusCode.RequestTimeout ：

"deadLetterReason":"MaxDeliveryAttemptsExceeded",
"deliveryAttempts":3,
"lastDeliveryOutcome":"TimedOut",
"lastHttpStatusCode":408,

现在，您可以在 deadLetterReason 属性中看到上述两种不同的情况，例如“ UndeliverableDueToHttpBadRequest ”和“ MaxDeliveryAttemptsExceeded ”

还有一件事：

• 启用死信后，事件网格将不立即将死信消息发送到死信端点，但要在300秒之后。我希望这是一个错误，并且会尽快修复。 实际上，如果订阅者在 HttpStatusCode.BadRequest 实例上失败，我们不能等待容器存储中的事件5分钟，它必须是接近实时的事件。