Service Bus Trigger Function with slots

[snesbitt76]

Can you please clarify how staging slots should be configured for functions that are ServiceBusTrigger functions? I have found that both my production slot and staging slot functions process distinct messages from the ServiceBus queue. My expectation based on this documentation is that only the production slot should process queue messages. Do we need to manually stop the staging slot after deployment to prevent this behaviour or is there an additional configuration setting for the staging slot to ensure it isn't triggered by queue messages?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 57567eca-a79e-5e41-3ab7-dc836ca08182
• Version Independent ID: 937e3455-0655-2a1f-9b54-f6b33277a816
• Content: Azure Functions deployment slots
• Content Source: articles/azure-functions/functions-deployment-slots.md
• Service: azure-functions
• GitHub Login: @craigshoemaker
• Microsoft Alias: cshoe

[PramodValavala-MSFT]

@snesbitt76 App Settings and Connection Strings should be made slot specific. So, depending on which slot the app runs in, it gets those settings.

[snesbitt76]

The default behaviour for app settings is to swap with the application. It is extra effort to define settings as slot-specific in ARM templates. Furthermore, one of the advantages of using slots in a CI/CD methodology is define the Release Pipeline to deploy a new version of the function to the staging slot and then swap it with the production slot. This pattern will always ensure that after the slot swap the staging slot contains an old version of the function and the production slot contains the new version. Why would the default behaviour be to have this old version still running and processing messages from the queue. No one would want this behaviour. The documentation is not clear that this is an expected side effect of using slots.

[PramodValavala-MSFT]

@snesbitt76 Only slot-specific app settings are swapped as mentioned under Swap Operations. And the old version still executes to handle any requests that it may have received before the swap operation.

Specifically for event sources, the doc quotes the following

Settings related to event sources and bindings need to be configured as deployment slot settings before you initiate a swap. Marking them as "sticky" ahead of time ensures events and outputs are directed to the proper instance.

[snesbitt76]

Thank you for clarifying. Appreciate it.

[PramodValavala-MSFT]

@snesbitt76 Glad we could help!

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

[ma499]

Dear @PramodValavala-MSFT does this advice apply across the board for all trigger types or just Service Bus triggers? For example, we make use of Cosmos DB triggers so I presume we would also use a slot specific configuration string setting.

What safeguards should we undertake for Timer Triggers in a staging slot? Presumably we can't stop the trigger from running and therefore all downstream configuration of data stores or queues that a Timer trigger may write to must also be slot-specific?

[benbelow]

@ma499 I'm also interested in the effect on Timer Triggers - I've previously been told by MS support that timer triggers are set up to only run once across all horizontal instances and slots, and that setting up 100% traffic to a production slot would ensure that a timer was only run on the production slot - but having read this thread I'm suspicious of that answer - it seems very unlikely that Timer triggers would account for that but service bus wouldn't.

Presumably if the solution for service bus is "sticky slots so they're not configured to read messages", the solution for Timers is "sticky slots with an empty crontab".

I'm a bit surprised by this solution though - surely just not configuring your event source for a service bus trigger in a staging slot would technically work, but lead to a lot of logged failures in Application Insights as the service bus function fails indexing?

@PramodValavala-MSFT do you have any thoughts on my logging concern above, or the question pertaining whether Timer Triggers are also run on staging and production slots?

[PramodValavala-MSFT]

@ma499 @benbelow Sorry for not getting back on this. The slot swap reroutes HTTP requests, but the other triggers would still listen against the configured connections in the staging slot.

In the case of Timer Trigger, even if you share the storage account between the slots, the hostid would be different as per this code.

And one stage, like you've mentioned, a different cron expression would make sense too.

[Ben-Duf]

@ma499 @benbelow I totally agree, I have the same issues.
I fount the doc about disabling functions.
I think we should disable those functions in the slot instead of setting them with a weird param.
Actually I don't find a value to disable all the functions from the slot.