I've got a function app that is configured as follows:
- It has a production slot and a slot called staging (i.e. normal slot setup)
One of the functions has a CosmosDBTrigger
Another of the function is a StatusCheck function used to delay swapping detailed here (https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-zero-downtime-deployment#status-check-with-slot)
In production using Azure release pipeline I deploy a new version as follows:
Deploy new version of code to slot
Wait for StatusCheck to return isRunning = false
Actual: The staging slot (i.e. that now has the "old" code) takes over. More specifically the CosmosDBTrigger on the staging slot appears to be "stealing" the Cosmos updates. If I stop the staging slot then the CosmosDBTrigger on the production slot wins out.
Expectation: That the production slot (i.e. the one with the "new" code) takes over without having to stop the staging slot
Am I missing anything here is there any configuration I need to modify to get the production slot (i.e. new code) CosmosDBTrigger to take over. I would assume the same type of deal applies to other triggers as well.