Why does my Azure Function sometimes stop being triggered

By Benjamin Perkins · · ,

Azure is so awesome because the features it provides are so very dynamic and flexible. The platform provides a starting point for the fruition of ideas, ideas only limited by ones imagination. With its dynamic nature and the flexibility it delivers to consumers, sometimes you just need a note to get your ideas optimally flowing on the platform.

Four points (for now) you need to keep in mind when creating and managing your Azure Function App:

  • All your Azure Functions run within a Azure Function App
  • The way in which you deploy your Azure Function is important
  • The trigger type you choose comes with scenarios specific only (in some cases) to that trigger type
  • Your endpoint must trigger/bind to only one Azure Function

Like with an Azure App Service, where each runs within its own W3WP process so does the Azure Function App. If you then access KUDU/SCM and navigate to the D:\home\site\wwwroot directory via the CMD console, you will see the Azure Functions which run inside that same W3WP process, Figure 1.

image

Figure 1, why does my Azure Function not get triggered, Azure Function stops

This correlates one-to-one with what is seen in the Azure portal, Figure 2.

image

Figure 2, why does my Azure Function not get triggered, Azure Function stops

There are numerous methods for deploying, managing and creating an Azure Function, I wrote a few methods here:

The issue most know for causing Azure Functions to not trigger is that some deployment or IDEs do not trigger a synchronization on a Consumption plan with the central listener. See here “New integrated portal for Azure Functions” and here “Document deployment options related to trigger syncing”. Those articles explain a bit more about this.

You can trigger a synchronization using the following PowerShell command.

Login-AzureRmAccount
Set-AzureRmContext -SubscriptionId "<Subscription Id>"
$WebAppApiVersion = "2018-02-01"
$ResourceType = "Microsoft.Web/sites"
$ResourceGroupName = "<Resource Group Name>"
$SiteName = "<Azure Function App Name>"
Write-Output "PowerShell function executed at:$(get-date)";
Invoke-AzureRmResourceAction
      -ResourceGroupName $ResourceGroupName
      -ResourceType $ResourceType
      -ResourceName $SiteName
      -Action syncfunctiontriggers
      -ApiVersion $WebAppApiVersion -Force

There are numerous trigger types and bindings. Here are a few:

Study each of the binding types and you learn the unique attributes of each.

Let’s say you have an Event Hub, then you create an Azure Function App, that includes an Azure Function which is triggered when messages are received into that Event Hub. If at some point in time later, you create a new Azure Function App (it doesn’t have to be a new Azure Function App, it could be a new Azure Function within the same Azure Function App) that includes an Azure Function that is triggered/bound to the same Event Hub as the other, then that one will begin getting the message and the original one will stop. You can only have one binding. That is why you seen in Figure 2, previously, that I have disabled some of my Azure Functions. This was because I had created another Azure Function App that included an Azure Function bound to the same Event Hub and Blob and disabling them was the solution for the scenario and experience I document here now.