如何在 Azure EventGrid 中的一批事件中触发重试/死信特定事件

Question

I've got an Azure app service with a REST API controller that can be called from Azure Event Grid. As you may know, Event Grid can send multiple events in a batch. I don't know under which circumstances this actually happens, because so far the event payload has always been an array consisting of only one single element, but the documentation makes it clear that there can be multiple events in one go.

Let's say I receive five events, and event #3 is somehow incorrect. How do I let Event Grid know that I've accepted four of the five events, and that it should retry or deadletter the third event?

[Route("api/[controller]")]
[ApiController]
public class EventGridController : ControllerBase
{
    [HttpPost("CustomerUpdated")]
    public async Task<IActionResult> CustomerUpdated()
    {
        // ... manage subscription validation here
        
        using var reader = new StreamReader(Request.Body, Encoding.UTF8);
        var eventStr = await reader.ReadToEndAsync();
        var gridEvents = JsonConvert.DeserializeObject<IEnumerable<GridEvent>>(eventStr);
        
        // ... let's say one of five received events is somehow incorrect here
        // ... how do I tell event grid which events failed and which events were accepted
    }

Currently, I mark the entire batch as failed by returning BadRequest() even if some of the events actually succeeded. It's an okayish "better safe than sorry" trade-off solution because I'm currently the lone ranger on this project and can as such make sure that my code is idempotent. But I want to make sure that some other developer in the future can't make the codebase non-idempotent and have data inconsistencies popping up all over the place because my code tells EventGrid that the entire batch was failed even though some of the events were actually processed successfully. What can I do?

Answer 1

The Azure Event Grid output batching policy is designed as All or None , see more details here .

In the case like you described, the subscriber needs to handle a logic for skipping already successful processed events and the return status code should be for retrying delivery (eg 503). Note, that the 400 Bad Request will immediately process of the deadlettering if it is enabled.