Open mathewc opened 7 years ago
@mamaso Thoughts on this one?
I think moving to StartAsync is the easy fix, I'm on board with that.
Worth it to consider incorporating this as well, where exceptions from the listen process itself are not handled: https://github.com/Azure/azure-webjobs-sdk/pull/1100
Gave this an attempt - unfortunately, it results in failures in service bus e2e tests. Will investigate further, but it's not as quick and easy a fix as I hoped.
For most of our listeners, all heavyweight operations are done within the scope of the listener StartAsync call. This has the benefit of allowing the host to start successfully in cases where 1 function listener might be in error.
However the ServiceBus listener has code outside of this error handling: https://github.com/Azure/azure-webjobs-sdk/blob/dev/src/Microsoft.Azure.WebJobs.ServiceBus/Listeners/ServiceBusQueueListenerFactory.cs#L34. An error here will bring the entire host down.
We should either move this logic into the listener StartAsync, or expand error handling to include such listener factory create operations.