In Azure DevOps, in a release pipeline, I specified Application Settings to be added/update:
[
{
"name": "HOSTINGSTARTUP__KEYVAULT__CONFIGURATIONENABLED",
"value": "true",
"slotSetting": false
},
{
"name": "HOSTINGSTARTUP__KEYVAULT__CONFIGURATIONVAULT",
"value": "https://******.vault.azure.net",
"slotSetting": false
}
]
The slot setting is set to false. However, in the end, it becomes true after the release step happens.
I tried deleting them and executing the release pipeline again but the HOSTINGSTARTUP__KEYVAULT__CONFIGURATIONENABLED slot setting flag is always set to true.
Why does this happen? How can I fix it?
After I deleted the settings and run the pipeline, the true value would come back.
However, after I set the "slotSetting" to false and deleted it, it started working correctly.
It seems like a bug to me but, in case you face a similar issue, do the above and it should start working again.
Related
We have an Azure function v3 running Node, consumption plan, with an input trigger connected to a cosmos database. The function.json looks like this:
{
"disabled": false,
"bindings": [
{
"type": "cosmosDBTrigger",
"name": "productDocuments",
"collectionName": "products",
"direction": "in",
"connectionStringSetting": "DB_CONNECTION_STRING",
"databaseName": "product-management",
"createLeaseCollectionIfNotExists": true,
"maxItemsPerInvocation": 1
},
{
"name": "productDocument",
"type": "cosmosDB",
"databaseName": "product-management",
"collectionName": "products",
"createIfNotExists": true,
"connectionStringSetting": "_DB_CONNECTION_STRING",
"direction": "out"
}
],
"scriptFile": "dist/nameOfFunction.js"
}
But this trigger is working really, really slow and unreliable. If we add an item to the DB it sometimes triggers straight away, sometimes it seems to take hours and sometimes not at all. I am manually monitoring the cosmos db so I can see that items are added.
I am looking at this page, and most of the time nothing happens. I don't know how else to debug this
Should it really take hours for an invocation to show up here? Or is it the trigger that's unreliable?
General guidance is in this doc: https://learn.microsoft.com/azure/cosmos-db/troubleshoot-changefeed-functions#my-changes-take-too-long-to-be-received
What happens on Consumption Plan is that, after a period of inactivity, instances are deprovisioned. When a new instance is provisioned, it hits a cold start.
The key part here is that, when your instances are deprovisioned, they are not checking the Change Feed for events, so how does Functions know when to "wake them up"?
There is a periodic check done by an external component that checks to see if there are new changes, if there are new, then it would provision new instances of your Function to start consuming them.
This external component in your case, could be having an issue or delays in this checks.
If you have no Function logs for an hour even though you are making changes to the monitored collection, I would try to contact Azure Support to understand why is your Function not "waking up".
One of the known issues I've heard about was related to where the Cosmos DB Connection Strings were stored. Apparently this component at some point (maybe it's already fixed) had a problem where it could not access the Connection String if it was saved in "Connection Strings" section of the Function configuration, but was looking for it only on the "App Settings". In this cases, it could not wake up the Function and the Function only woke up if someone opened it on the Azure Portal. My recommendation would be to check where are you storing your connection string and see if you can move it to "App Settings" and see how it behaves.
Our problem with this was that we had two separate functions that both had a CosmosDBTrigger on the same collectionm but used the same lease, and apparently you can't do that. So it was solved by setting two separate leases (we used the leaseCollectionPrefix in the function.json.)
I am using a Function app with cosmos DB trigger, when running locally, the behavior is very strange as I stop receiving events randomly, like if the connection to the Lease collection drops. I am getting an error message that says a read operation fails to Blob storage, but not sure if this is related. Here's the error:
There was an error performing a read operation on the Blob Storage Secret Repository.
Please ensure the 'AzureWebJobsStorage' connection string is valid
I am running the function app with this code: func host start --cors * --verbose
And here's the CosmosDBOptions object I can see in the console:
[2021-02-09T16:17:58.305Z] CosmosDBOptions
[2021-02-09T16:17:58.307Z] {
[2021-02-09T16:17:58.307Z] "ConnectionMode": null,
[2021-02-09T16:17:58.308Z] "Protocol": null,
[2021-02-09T16:17:58.309Z] "LeaseOptions": {
[2021-02-09T16:17:58.310Z] "CheckpointFrequency": {
[2021-02-09T16:17:58.310Z] "ExplicitCheckpoint": false,
[2021-02-09T16:17:58.311Z] "ProcessedDocumentCount": null,
[2021-02-09T16:17:58.311Z] "TimeInterval": null
[2021-02-09T16:17:58.312Z] },
[2021-02-09T16:17:58.313Z] "FeedPollDelay": "00:00:05",
[2021-02-09T16:17:58.313Z] "IsAutoCheckpointEnabled": true,
[2021-02-09T16:17:58.314Z] "LeaseAcquireInterval": "00:00:13",
[2021-02-09T16:17:58.314Z] "LeaseExpirationInterval": "00:01:00",
[2021-02-09T16:17:58.315Z] "LeasePrefix": null,
[2021-02-09T16:17:58.316Z] "LeaseRenewInterval": "00:00:17"
[2021-02-09T16:17:58.316Z] }
[2021-02-09T16:17:58.323Z] }
and my host.json file:
{
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
}
}
},
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[1.*, 2.0.0)"
}
}
Finally, that issue started since I added a shared folder, not sure if it's related but it's really annoying, deleting leases collection solves temporary the problem but It costs a lot of time and all the other running functions break because I clean all the collection.
TLDR; Using the CosmosDB emulator for local development solves this issue, as you won't have two functions pointing to the same lease collection.
There are two important points:
If you have one Azure Function deployed on Azure and one running locally in your machine with the same lease configuration listening for changes in the same monitored collection then these will behave as multiple instances of the same deployment and changes will be delivered to one or the other and you might experience "event loss" on the one running in Azure. This is documented in https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-changefeed-functions#some-changes-are-missing-in-my-trigger. If you want to have 2 independent Functions listening for changes in the same monitored collection, sharing the same lease collection, you need to use the LeaseCollectionPrefix configuration https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-create-multiple-cosmos-db-triggers
The error you are seeing locally is potentially related to either not having the Azure Storage emulator running or not configuring the AzureWebJobsStorage configuration locally to use it. Azure Functions runtime (regardless of the Cosmos DB Trigger) requires a storage account. You can use UseDevelopmentStorage=true for the local storage emulator.
With below mentioned host.json, we see that function timeout is set to default of 30 mins. Some of our workflows run beyond 30 mins. This was working in runtime ~2. Also by checking the logs from host startup, there is no way to see the timeout value picked by the runtime. Is it logged ?
{
"version": "2.0",
"functionTimeout": "02:00:00",
"logging": {
"logLevel": {
"Default": "Debug"
}
}
}
The host.json is correct, the version is just for the schema.
I just had a similar issue, and it turns out registering IConfiguration as a singleton re-instates the default values.
So do not do this in Startup.cs:
builder.Services.AddSingleton<IConfiguration>(config);
We have started to use the Queue binding in our Azure functions for longer-running tasks such as sending bulk e-mails and "clean-up" tasks for CosmosDB. We develop locally with the Functions emulator then commit into VSTS/Azure DevOps which then auto-deploys into our Function App.
It seems as though pretty quickly we're going to have multiple Functions (two local emulators and one cloud function) all listening to the same queue. We tried disabling locally and renaming locally, but these all seem like awkward workarounds that require too much manual work and have the possibility to push the wrong queue name forward into VSTS.
How do we configure the queue name in the function.json to read an environment variable? The connection setting in the binding takes the name of an environment variable, but the queue setting wants a string.
{
"disabled": false,
"bindings": [
{
"name": "myQueueItem",
"type": "queueTrigger",
"direction": "in",
"queueName": "emailer",
"connection": "STORAGE_CONNECTION_STRING"
}
]
}
Just wrap variable name with % and function can read its value from Application settings on portal and Values in local.settings.json locally.
"queueName": "%myqueue%"
connection property of triggers and bindings is a special case and automatically resolves values as app settings, without percent signs.
See Binding expressions - app settings.
I am just starting to test with Microsoft Azure Functions. I have my VS2017 publishing and my function is working nicely. I currently have one function that I am working with. It is set on a timer of every 5 minutes.
However, it appears that that function is executing even when I have it "disabled". This can be seen in the Monitor and in one of the systems that it is interacting with. The only way that I am able to stop it is to stop the overall function group. When I then start the function group, it starts the disabled function running every 5 minutes again.
Am I missing something? Does the disabling of an individual function have some other purpose?
How do I get an individual function within a function group to not execute on its defined schedule?
Thanks.
What you are experiencing is an expected behavior though not an ideal one. It is a bug in the portal experience.
The Function runtime directly consumes metadata in the binary files of the pre-compiled functions. Here is sample of annotation for the disabled function.
[TimerTrigger("0 */5 * * * *"), Disable()]
This is the function.json generated by visual studio the above annotations.
{
"generatedBy": "Microsoft.NET.Sdk.Functions.MSBuild-1.0.2",
"configurationSource": "attributes",
"bindings": [
{
"type": "timerTrigger",
"schedule": "0 */5 * * * *",
"useMonitor": true,
"runOnStartup": false,
"name": "myTimer"
}
],
"disabled": true,
"scriptFile": "..\\bin\\FunctionApp3.dll",
"entryPoint": "FunctionApp3.Function1.Run"
}
The function.json generated by the precompiled functions is consumed by the portal and that is what is shown in the portal. When you change the disabled state of the function in the portal the disabled property is changed in the function.json but it is not consumed by the functions runtime. Hence it continues to execute.
When you deploy it in disabled state, runtime is aware of it and honors it as expected.
I have opened this bug to fix the portal experience.
https://github.com/Azure/azure-functions-ux/issues/1857
Today, I got the same problem, and after to disable the function in Azure, I recommend you to restart the Function service. Because the Azure needs to refresh the metadata, and the restart is one of the solutions to accomplish it.