When a handler that is processing a competing event throws an exception, the current code travels to the DeliverAfter within the transport. This is making the assumption that it is a queue, which in the WSB/ASB extension it looks to create if it does not exist - however for an event that is published it is a topic. That seems to be the root cause of the exceptions in the logs where it is trying to create a queue for an already existing topic.
An integration test has been added to cover the scenario. I have run them against an azure service bus subscription to validate that it will go into the dead letter queue, etc.
Ref #251 .
When a handler that is processing a competing event throws an exception, the current code travels to the DeliverAfter within the transport. This is making the assumption that it is a queue, which in the WSB/ASB extension it looks to create if it does not exist - however for an event that is published it is a topic. That seems to be the root cause of the exceptions in the logs where it is trying to create a queue for an already existing topic.
An integration test has been added to cover the scenario. I have run them against an azure service bus subscription to validate that it will go into the dead letter queue, etc.