Очередь хранилища Azure - обработка сообщений в подозрительной очереди

Для вашей конкретной проблемы я бы порекомендовал решение, упомянутое в части вопроса этого сообщения: Azure: как переместить сообщения из подозрительной очереди обратно в основную очередь?

Обратите внимание, что имя очереди заражения == $"{queueName}-poison"

Вы можете использовать Azure Management Studio (cerulean) и переместить сообщение из опасной очереди в фактическую очередь. Настоятельно рекомендуемый инструмент для доступа к очередям и BLOB-объектам, а также для выполнения любых действий, связанных с производством. https://www.cerebrata.com/products/cerulean

Я просто пользуюсь этим инструментом и никоим образом не являюсь аффилированным лицом, я рекомендовал, потому что он очень мощный, очень полезный и делает вас очень продуктивным.

Нажмите «Переместить», и сообщение можно будет переместить в уже загруженную очередь.

В моем текущем проекте я создал то, что называется: «Вспомогательные функции» в FunctionApp. Он предоставляет специальную конечную точку HTTP с уровнем авторизации Admin, которая может быть запущена в любое время.

См. Приведенный ниже код, который решает проблему повторной обработки сообщений из опасной очереди:

public static class QueueOperations
{
    [FunctionName("Support_ReprocessPoisonQueueMessages")]
    public static async Task<IActionResult> Support_ReprocessPoisonQueueMessages([HttpTrigger(AuthorizationLevel.Admin, "put", Route = "support/reprocessQueueMessages/{queueName}")]HttpRequest req, ILogger log,
        [Queue("{queueName}")] CloudQueue queue,
        [Queue("{queueName}-poison")] CloudQueue poisonQueue, string queueName)
    {
        log.LogInformation("Support_ReprocessPoisonQueueMessages function processed a request.");

        int.TryParse(req.Query["messageCount"], out var messageCountParameter);
        var messageCount = messageCountParameter == 0 ? 10 : messageCountParameter;

        var processedMessages = 0;
        while (processedMessages < messageCount)
        {
            var message = await poisonQueue.GetMessageAsync();
            if (message == null)
                break;

            var messageId = message.Id;
            var popReceipt = message.PopReceipt;

            await queue.AddMessageAsync(message); // a new Id and PopReceipt is assigned
            await poisonQueue.DeleteMessageAsync(messageId, popReceipt);
            processedMessages++;
        }

        return new OkObjectResult($"Reprocessed {processedMessages} messages from the {poisonQueue.Name} queue.");
    }
}

В качестве альтернативы может быть хорошей идеей создать новое сообщение с дополнительными метаданными (поскольку информация о том, что сообщение уже было обработано в прошлом безуспешно - тогда оно может быть отправлено в очередь недоставленных сообщений).

У вас есть два варианта

1. Добавьте еще одну функцию, которая запускается сообщениями, добавленными в подозрительную очередь. Вы можете попробовать добавить содержимое в базу данных в этой функции. Более подробную информацию об этом подходе можно найти здесь. Конечно, если эта функция тоже не может обработать сообщение, вы можете проверить количество исключений из очереди и опубликовать уведомление, которое требует ручного вмешательства.
2. Добавьте параметр int 'dequeueCount' в функцию, обрабатывающую очередь, и после, скажем, 5 повторных попыток регистрируйте сбой вместо того, чтобы позволить сообщению перейти в опасную очередь. Например, вы можете отправить электронное письмо, чтобы уведомить о необходимости ручного вмешательства.

Просто укажите своей функцией Azure в очереди с ошибками, и элементы в этой очереди будут обработаны. Подробнее здесь: https://briancaos.wordpress.com/2018/05/03/azure-functions-how-to-retry-messages-in-the-poison-queue/

Обозреватель службы хранилища Azure (версия выше 1.15.0) теперь поддерживает перемещение сообщений из одной очереди в другую. Это позволяет переместить все или выбранный набор сообщений из опасной очереди обратно в исходную очередь.

https://github.com/microsoft/AzureStorageExplorer/issues/1064