17

I have tried many things but the only way I can force AzFn to understand the invocation has failed, is to throw an exception and not handle it. So, if I return an HttpResponseException, AzFn will consider the invocation as a success. That feels wrong.

catch (Exception ex)
    {
        logger.Error($"{nameof(ex)}: {ex.Message}", ex);
        response = req.CreateErrorResponse(HttpStatusCode.InternalServerError, ex.Message, ex);

    }

This should produce an invocation marked as fail but it doesn't.

imbageek
  • 609
  • 5
  • 18
  • Given official doc is not much in detail but will give overview about how azure function retry on exception https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-error-pages – Oomph Fortuity Nov 29 '18 at 11:57

1 Answers1

21

Any exception thrown from your function will mark the function as failed. In your code above you're swallowing the exception, so we consider it successful. If you instead rethrow the exception, the function will be marked as failed. We'll automatically return a 500 in such cases on your behalf.

We don't look at the HttpStatusCode you return to determine if the function is successful, only whether the function ran successfully to completion w/o exception. If your function is able to return a response, it is successful from our point of view.

mathewc
  • 13,312
  • 2
  • 45
  • 53
  • Thanks. Makes sense - couldn't find any specifics or best practice in the documentation about this. – imbageek Mar 21 '17 at 14:03
  • 2
    That makes sense, but it seems that if you throw an uncaught exception to mark the job as failed, then the output bindings are ignored. – Métoule Jan 17 '19 at 08:52
  • This approach won't work if you have an ServiceBus output binding **and** you deliberately deferred/dead-letter or did something else with the message. The service tries to abandon the message but the lock is not valid anymore – hwcverwe Aug 31 '20 at 09:54
  • 9
    I don't think this is useful. In an exception scenario, ideally one would want to return a short and helpful response to caller while still logging the exception and marking this request as failed. – Nitin Badole Nov 19 '20 at 09:56
  • 2
    I totally agree with @NitinBadole. The current mechanics are misleading. – Dominik Dec 26 '20 at 11:06
  • 1
    @mathewc The above code is not swallowing exception. It is handing it and returning short message to caller rather than full stack trace the message could also have Execution Context Id for help lookup the specific execution for support. It doesn't have to be specific HTTP status code to determine a request as a failure. A flag on Execution Context could be sufficient to mark request as failure. – Nitin Badole Dec 31 '20 at 18:19
  • While this gets the job done, it is quite misleading for us as we now have loads of exceptions in AppInsights which is not ideal. In our case, our logic needs to fail a message so the system can retry at a later time so this isn't an exceptional case. – GETah Feb 07 '21 at 09:08
  • 3
    @mathewc Is this still the case? We need to return a helpful message to the caller and at the same time mark the function as `Failed`. Combining `return` and `throw` is impossible. – Serj Dec 21 '21 at 21:13