search

Azure / azure-functions-eventhubs-extension

Event Hubs extension for Azure Functions
MIT License
20 stars 26 forks source link

Checkpoint progressed on internal azure function exceptions #66

Closed xzuttz closed 2 years ago

xzuttz commented 4 years ago

The current EventHubListener.cs implementation progresses the checkpoint if there is an unhandled exception in user code.

See EventHubListener.cs:

https://github.com/Azure/azure-functions-eventhubs-extension/blob/e263c0c09b360d7b8ab31c4767e58bc99a1e36ad/src/Microsoft.Azure.WebJobs.Extensions.EventHubs/Listeners/EventHubListener.cs#L155-L227

Unfortunately, internal exceptions in DryIoC are treated as user exceptions, and the user has no way of catching them.

https://github.com/Azure/azure-webjobs-sdk/issues/2432 https://github.com/Azure/azure-functions-host/issues/5240

Fixing the DryIoC exceptions is one thing. There is however no guarantee that such situations will not occur again.

I propose a slighty modified flow, where the user is able to decide whether the checkpoint should be progressed or not, if there is an unhandled user exception. This can be done through a setting in host.json.

I forked the repo and made a pull request to demonstrate. There is also a MyGet package if you want to test. Currently, in the PR, it is hardcoded to not progress the checkpoint.

PR: https://github.com/xzuttz/azure-functions-eventhubs-extension/pull/1

If you are interested in pursuing the proposal I am happy to complete the pull request with any further instructions.

Albeit I am not able to really reproduce the DryIoC exception in a test environment, we can reproduce that DryIoC exceptions, in the function scope, will be treated as user exceptions, by doing the following:

  1. Create a HTTP trigger
  2. Set a breakpoint in FunctionExecutionFeature.cs.
  3. Call the HTTP trigger through its URL Visual Studio will stop at the breakpoint in step 2
  4. Create a breakpoint in Container.cs
  5. Push F5 or the "Continue" button i VS to continue the flow Visual Studio will stop at the breakpoint in step 4
  6. In Visual Studio, move the pointer to the next line, forcing an exception, and push F5 or" Continue" to continue the flow.

The HTTP trigger will not return.

The logs will say that the DryIoC exception came from the HTTP trigger context, thus the checkpoint will be progressed by the EventHubListener.

drdamour commented 4 years ago

i was surprised by this behaviour, but stream hub really is suppose to just keep chugging away. retries and an optional poison hub might make sense for certain scenarios. I've found it advances it even if it's more extension type exceptions like json deserialization error in the binding. i'd love to throw those to a poison queue and keep on chugging.

alrod commented 2 years ago

this can be closed once we merge the PR: https://github.com/Azure/azure-functions-eventhubs-extension/pull/105

alrod commented 2 years ago

Closing as fix for DryLoc exception is merged.