Azure-webjobs-sdk: 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.

[JoeBrockhaus]

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]

@JoeBrockhaus, did you ever find what caused this? I don't think that these changes you've seen were due to Azure Functions.

This reset that you've seen goes outside the scope of anything Functions will do. As you've found in NamespaceManagerExtensions, we will create Queues, Topics, and Subscriptions if they do not exist, but there is no other logic for management operations on these items. Anything we create is with default settings and only created if it does not exist.

[rikvandenberg]

We are kinda running in a similar issue. We have updated our packages to azure-webjobs-sdk version 2.0. We are using an azure service bus queue which will be populated by requests received through our Web API. Our azure web jobs then handles all our messages sent to our Queue's

Azure Storage Queue's

Previously, we were using Azure Storage Queue's, and only recently made the switch because of requirements. With Storage Queue's, we didn't see our queue's being created until our Web API code was called to check if the Storage Queue already exists. This was done before adding our messages to the queue. If not, we created the queue and then added our messages/commands.

Azure Service Bus Queue

Now after switching to Azure Service Bus Queues, during deployment of our ARM template, we found it strange that our queue was already created in our service bus, without being called first. Turns out, because we have a continuous running web job and a method marked with the ServiceBusTriggerAttribute, it will create the service bus for us in the default settings. That is fine for now, but later, we want to have more control over the settings, and thus the validation if the queue already exist, is not sufficient anymore. We need to check if the settings match our expectations.

// This method triggers the sdk to create the service bus queue 
public void Process([ServiceBusTrigger("%QueueName%")] BrokeredMessage brokeredMessage, TextWriter textWriter)
{
    var queueMessage = brokeredMessage.GetBody<string>();

    // Dispatch queue message to our internal processor
    _webJobDispatcher.Dispatch(queueMessage, brokeredMessage.EnqueuedTimeUtc, textWriter);
}

Shared Access Keys

This creation is actually handled by the SharedAccessKey provided in the config. If the key only has Listen permissions, the web job will not startup, and throw an exception caused by the 401 Unauthorized response when trying to create the Service Bus Queue.

using (JobHost host = new JobHost(config))
{
    // Exception 401 because Key doesn't have manage permissions.
    host.RunAndBlock();
}

However, when specifying AccessRights.Listen in the trigger attribute, with a listen only key, the RunAndBlock method will throw a 404 Not Found. Edit: This is caused because there is no queue after deployment, and we have want to give Web API the manage permissions for our queue's.

public void Process([ServiceBusTrigger("%QueueName%", AccessRights.Listen)] BrokeredMessage brokeredMessage, TextWriter textWriter)

Question

So this leaves me with the question, if the azure-webjobs-sdk triggers the creation of the Azure Service Bus Queue, is there a way to hook into this to specify the required settings to prevent a creation of a service bus to in the settings?

[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?

[rikvandenberg]

@mamaso That should be Ok. We were kinda expecting that we needed to write some deployment/custom code in order to hook into this.

I've skimmed through the documentation and saw this error/case specified with Azure Functions here. It contains a note about the connectionstring requiring Manage permissions.

Is it a suggestion to also update the documentation regarding Azure Web Jobs SDK and the ServiceBusTriggerAttribute, located here?

[mamaso]

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

[mamaso]

https://github.com/Microsoft/azure-docs/pull/1044