We recently had an issue regarding a function in an Azure Function App Service that was still running after being disabled using the Azure Portal (and hence the function.json)


The Setup

We used an Azure Function App Service running on an App Service Plan. The timer triggered function was precompiled using C# (so a .dll) developed in Visual Studio 2017.


Disabling a timer triggered function

We needed to stop the function because of corrupt data entering the underlying system, so we toggled the state using the azure portal, as functions themselves are not accessible using Power Shell  (only the Functions App Service itself is)

As expected, the function.json showed the disabled state

But immediately we noticed that the function was still running, and the function monitor showed those further executions.

After some trials we contacted the Microsoft Support and discovered, that this toggle does in fact not work with precompiled functions. Because unlike we expected the runtime does not check the property before entering the code. The environment just runs the function and because it is precompiled it was unchanged, hence disabling had no effect.

When we tried to deploy it with the disabled attribute in place, the function would not run, even though we had set disabled to false using the Azure Portal. This of course confirms what the MS Support already told us. Oddly enough, the function ran when triggered manually using the portal.

One workaround now was to redeploy when we wanted to change the disabled state of the function using that static [disabled] attribute. Obviously, this was not a „solution“ that solved anything.

Finally, we got the advice that it is possible to tie the disabled state of a function to an app setting in the Function App Service.



Following the advice on implementing a disabled state of the function depending on an app setting we ended up with this code

With PosTransactionToServiceBus-Disable being the app settings name that contained the value for the disabled state of the function.

This solution works as the upcoming functions environment runtime v2 will work per default (so we were told). This procedure makes a lot of sense and so we deployed it that way. The Function.json now looks as following

This is helpful because everyone now can see where the value for the disabled property comes from.

While this is a good and workable solution it still has one odd point. When you attempt to disable the function using the Azure Portals switch, it will change the function.json. But because it is a precompiled function, nothing changes but the displayed disabled state of the function, thereby loosing the information where to find the used value without having the read the code.