ServiceBusTrigger pointing at Topics/Subscriptions which don't exist seem to cause ALL Subscriptions (and their Rules) on the Topic to be reset to defaults.

I’ve filed an Azure Support Ticket for this in order to gain more insight to when/from where these changes were initiated, but based on the behavior I’m seeing, I can only assume it’s the WebJobs SDK.

I’m not sure if this only occurs when debugging the jobs locally, or if it would also occur while running on an AppService. (though this distinction seems dubious to me…)

I believe the problem occurred when I deleted a few Subscriptions from the Topic which still had (inactive/unused) Triggers defined in the WebJobs code. It appears the SDK sees the bound Topic+Subscription does not exist, and then for whatever reason, recreates all bound Subscriptions.

In my case, I have a series of topics, each with a few subscriptions, and the subscriptions have rules which filter certain messages into certain subscriptions for processing by the various subscription-specific triggers+functions. While debugging, I was getting flooded with numerous unexpected exceptions as the message bodies were seemingly corrupted.

In reality, what was happening is that because the Subscriptions got mysteriously reset, MaxDeliveryCount was back at 10 (not 1, as configured), TTL, Lock, and Expiration settings were all defaulted to some extraordinarily high value (Lock 1min, not 5), and the Message Property filters on the Subscriptions were getting reset to 1=1, so that every Message was getting dropped into every Subscription, so every Trigger/Function was firing and throwing more messages back onto the same Topic, flooding everything to death.

I remember at one point auto-creation of ServiceBus Topics/Subscriptions was not supported, and I can find no documentation on this feature either. If this is indeed intentional behavior, it could be very useful (I would no longer have to manually setup the entities using Service Bus Explorer), but I would most certainly need to be able to configure all the various settings that are fundamental to the architecture of our application.

I did a little digging and found the NamespaceManagerExtensions… but on the surface this does not seem like it should be eliciting the behavior I’m seeing, since it checks if the Subscription exists (unless that check or this parentSubscriptionName = SplitQueuePath(name)[0]; is somehow flawed). Is this the code behind the 2.0.0-beta2 release?

Microsoft.Azure.WebJobs.ServiceBus - 2.0.0-beta2

[mamaso]

@rikvandenberg sounds good, I’ll look at updating the webjobs doc

[mamaso]

Ok, quick summary:

• If a queue does not exist before RunAndBlock():
  • Manage rights: webjobs will create the queue with default settings (these are not configurable)
  • Listen rights: webjobs will throw an error, as it cannot create the queue
• If the queue already exists, webjobs will use it (access rights do not come into play)

If you want to prevent creation of queues, simply set AccessRights.Listen in the trigger. You’ll need to ensure that the queue is created before RunAndBlock() - you can do this via the service bus sdk in a deployment script (perhaps the script that deploys your arm template, or the web apps deployment script.

Is this sufficient for your scenario?