better error handling for EventGrid calls that you want to retry
The Microsoft sample documentation (link below) suggests using a Run method with void return type. This doesn't allow convenient handling of errors that you want to handle by getting EventGrid to retry invoking the Azure Function again after a period. For example, my Azure Function sends a message to a server (Azure Container Instance) which may be down. In this situation I want EventGrid to invoke my Azure Function again after a period when the server might be up. However, with a void return type my only option seems to be that of throwing an exception (InvalidOperation?). Agreed, I could use Run([(HttpTrigger(…)]…). However, what's the point of having [EventGridTrigger] if it's not going to be used?
By the way, I tried using a return type of HttpResponseMessage with Run[EventGridTrigger] and whilst it built, it reported an error at runtime Cannot bind parameter '$return' to type HttpResponseMessage&.
public static void Run([EventGridTrigger]JObject eventGridEvent, TraceWriter log)
This continues to be something we plan to do. No updates regarding ETA at this time.
Steve Pettifer commented
I would agree that this could be a useful addition. We are starting to use event grids with functions and in some circumstances there are events that we would like to immediately dead letter when we encounter them in the function. It would seem rather nicer to be able to explicitly return a 400 rather than just throwing an exception. In fact there seems to be very little mention anywhere of how to get something to go to the dead letter queue: I cannot find an explicit explanation of whether an exception is treated as a 500 or something else (and 500 would make more sense for an exception thrown in the function). We even considered switching to an http trigger so we could do this but that also introduces other complexities such as being responsible for handling the validation call and we decided it wasn't quite worth the effort. None of this is a deal breaker by any means but there are scenarios where you might want to send something straight to the dead letter quue to be handled by some other process and it's not easy to do that.
Oliver Tomlinson commented
I initially thought the same, but came to the conclusion of "why not just throw an exception?"
EventGrid has a simple job and that is to keep trying to deliver the message to the subscriber until it is completed sucessfully.
EventGrid really doesn't care *why* your function failed, I assume it treats any non-200 response as a failure and will invoke retries until it completes successfully or the 24 hour retry period elapses.
My opinion but having to explicitly return a Type that defines the success is unnecessary in this particular binding, as the EventGridTrigger is abstracting you from the complications of returning success or failure state.