Где хранятся помещенные в очередь сообщения о событиях запуска BLOB-объекта Azure Event Grid и как их очистить?

Сетка событий автоматически повторит доставку сообщения, если при попытке доставки будет возвращено что-либо, кроме 200 или 202 (ОК / Принято). По умолчанию он будет повторять попытку в течение 24 часов и использует экспоненциальное резервное копирование, которое добавляет дополнительное время между каждым запросом, пока он не сработает. Вы видите, что процесс по умолчанию запущен. (Вы также можете настроить обработку недоставленных сообщений с помощью учетной записи хранения, чтобы недоставленные сообщения сохранялись где-то в случае сбоя).

Скорее всего, вы ищете политику повторных попыток, которую вы можете создать при создании подписки. Уверен, что вы можете установить максимальное количество попыток доставки равным 1, чтобы он не повторял попытку (и без включения поддержки недоставленных писем сообщение по существу будет отброшено). Более подробную информацию об этом можно найти на https://docs.microsoft.com/en-us/azure/event-grid/manage-event-delivery#set-retry-policy

Я не знаю ни одного способа «исключить из очереди» уже отправленные сообщения без этой политики повторных попыток - возможно, вам придется удалить и воссоздать подписку на эту тему сетки событий.

В дополнение к ответу @JoshCarlisle и более ясному событию Event Доставка сообщения в сетке и повторная попытка документ:

Мертвые буквы включают особый случай в логике политики повтора. В случае, если мертвые буквы - это включение и у подписчика произошел сбой с 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 минут событие из хранилища контейнера, это должно быть событие, управляемое близко к реальному времени.