Блог

На прошлой неделе я пытался реализовать распространение событий через сетку событий с помощью webhooks, и я столкнулся с проблемой, когда, даже если подписчик возвращает код ошибки, который должен вызвать повторную попытку (любую из https://docs.microsoft.com/en-us/azure/event-grid/delivery-and-retry#failure-codes ), но этого просто не происходит. отображается конфигурация политики повторных попыток. В настоящее время сервер всегда отвечает 503, что теоретически должно отмечать события как не доставленные . Есть ли что-то, чего мне не хватает?

О, и я, вероятно, должен упомянуть, что я регистрирую все события, и события проходят только один раз.

Ниже приведен пример тестирования политики повторных попыток с параметром «мертвые буквы». Все функции работают очень хорошо.

1. У меня есть настраиваемая тема (topicTester100) для запуска события

     [
      {
        "topic":null,
        "id":"690bb0ec-7aad-4ed9-a7a1-3b6c8899c57c",
        "subject":"/myapp/vehicles/motorcycles",
        "eventType":"retrytest",
        "eventTime":"2020-12-03T14:15:46.660",
        "data":{
          "make":"Ducati",
          "model":"Monster"
        }
      }
    ]
    

2. Существует подписка (Tester —17158468) на эту тему со следующими свойствами:

    {
    "name":"Tester--17158468",
    "type":"Microsoft.EventGrid/eventSubscriptions",
    "id":"/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.EventGrid/topics/testerTopic100/providers/Microsoft.EventGrid/eventSubscriptions/Tester--17158468",
    "properties":{
      "topic":"/subscriptions/xxxx/resourceGroups/xxxx/providers/microsoft.eventgrid/topics/testertopic100",
      "provisioningState":"Succeeded",
      "destination":{
        "properties":{
          "endpointUrl":null,
          "endpointBaseUrl":"https://xxxx.azurewebsites.net/api/HttpEventGrid",
          "maxEventsPerBatch":1,
          "preferredBatchSizeInKilobytes":64
        },
        "endpointType":"WebHook"
      },
      "filter":{
        "subjectBeginsWith":"",
        "subjectEndsWith":""
      },
      "labels":[
        ""
      ],
      "eventDeliverySchema":"EventGridSchema",
      "retryPolicy":{
        "maxDeliveryAttempts":4,
        "eventTimeToLiveInMinutes":20
      },
      "deadLetterDestination":{
        "properties":{
          "resourceId":"/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.Storage/storageAccounts/rk2018ebstg",
          "blobContainerName":"eventgrid"
        },
        "endpointType":"StorageBlob"
      }
    }
    }
    

   Обратите внимание, что счетчик доставки = 4 и TTL = 20 минут.

3. Подписчик реализован как функция HttpTrigger, где логика для уведомлений следующая:

     else if(eventTypeHeader == "Notification") 
    {   
        log.LogInformation($"Notification message: [id = {jtoken["id"]}, eventType = {jtoken["eventType"]}]");
   
        return jtoken["eventType"].Value<string>() == "retrytest" ? (ActionResult)new StatusCodeResult(503) : (ActionResult)new OkResult();
    }
    

   Как вы можете видеть в приведенном выше фрагменте кода, если EventType имеет значение retryTest , подписчику будет возвращен код состояния = 503, в противном случае код возврата равен 200.

4. В следующем фрагменте экрана показаны сообщения журнала подписчика:

   

   Как вы можете видеть в приведенных выше журналах, сообщение о событии (id = 690bb0ec-7aad-4ed9-a7a1-3b6c8899c57c) было доставлено три раза: первое доставляется немедленно, второе — через 1 минуту, а последнее, например, третье, — через 10 минут. Следующая доставка была запланирована через 60 минут, но эта доставка превышает определенное время TTL в подписке, например, 20 минут, поэтому сообщение может быть либо удалено, либо, если у нас включена опция «мертвые буквы», сообщение отправляется через 5 минут (не настраивается) в хранилище больших двоичных объектов, смотрите Следующий фрагмент экрана:

   

   Обратите внимание, что существует еще одна подписка (TESTER -169394031), подписанная на учетную запись хранилища с той же конечной точкой weebhook, что и первая, поэтому мы можем видеть в журналах событие, основанное на сохранении сообщения с мертвыми буквами в хранилище больших двоичных объектов.

5. Следующий фрагмент экрана показывает сообщение с мертвыми буквами:

   

   Как вы можете видеть, есть исходное сообщение о событии с подробным описанием причины сбоя доставки.