Open Sti2nd opened 2 years ago
I am also facing a similar error when trying to load TimerTrigger configuration from Azure App Configuration.
Microsoft.Azure.WebJobs.Script: The functions scale controller may not scale the following functions correctly because some configuration values were modified in an external startup class.
Function `Function1` uses the modified key(s): %ScheduleConfig%
I have the same service bus error:
The Functions scale controller may not scale the following functions correctly because some configuration values were modified in an external startup class. [2022-06-16T07:07:10.924Z] Function 'ProcessJobs-Other' uses the modified key(s): ServiceBusConnectionString [2022-06-16T07:07:10.925Z] Function 'ProcessJobs-Selenium' uses the modified key(s): ServiceBusConnectionString
This has been since an upgrade from .net core 3.1 to .net 6
Have the same issue with the TimerTrigger and schedule loaded from Azure App Configuration. Can you please provide an update on how to fix it (without using the "local" app settings for the schedule)
@Sti2nd can you share your configuration injection defined in your startup? are you adding environment variables as a source by chance?
Not working on that project right now but we are still stuck on Azure.Functions.Extensions" Version="1.0.0"
so I'll ask a colleague if he has time to share something.
I have the same error when trying to read config value for ServiceBusTrigger queue name from external configuration provider(azure app configuration, azure key vault or my custom one)
Are binding expressions limited to environment variables only? If it's the case then it must be at least documented somewhere. I haven't found anything related here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-expressions-patterns
Hello. Still an issue in 2023.
I have this issue as well. Loading my config values from Azure keyvault.
@fabiocav I am forever off this codebase, so unfortunately won't be able to help. Should the issue be closed?
I have this issue as well. Loading my config values from Azure keyvault.
Not sure if there is another alternative for this. Had to eventually duplicate the settings in the function app settings.
As @patokenneth mentioned, I fixed the issue by adding value as an app setting in Configurations. But it makes the extension useless.
Sorry for the delay on this, is anyone facing the issue able to share a minimal repro project for me debug and investigate?
I would help to have the csproj, the startup file uses and any other config/settings files
I can not share the repo right now. But you can easily reproduce it.
[FunctionName("notify-offer-status")] public async Task RunAsync([ServiceBusTrigger("notification-offer-status", Connection = "AzureServiceBus")] TriggerParams myQueueItem, ILogger log)
For reading connection, I added the "AzureServiceBus" parameter to the configuration below
This warning is by design if loading configuration from an external source in a SKU that has a dependency on the scale controller for activation.
If configuration is read in in the startup (in the host process), the platform (in this case, the scale controller) will not have access to that configuration to properly activate and scale your application.
Reading this configuration would work in SKUs without the scale controller dependency (any model without dynamic scaling, like dedicated).
This could be related to Runtime Scale Monitoring not being enabled - https://github.com/Azure/azure-functions-host/issues/6542#issuecomment-820954390. It is also potentially related to https://github.com/Azure/azure-functions-host/issues/7210.
I get the following error in Azure when using version 1.1.0 (of Microsoft.Azure.Functions.Extensions):
This message is a warning locally, but an error on Azure that prevents the whole Function app from working.
The issue https://github.com/Azure/azure-functions-host/issues/6542 suggests that it is because on the Consumption plan the scale controller cannot access the environment variables. I have no reason to disbelieve that, but the exact same code works using version 1.0.0, so apparently using the old version the scale controller can access the environment variables.
I have not found that it is mentioned in the release notes of 1.1.0 that there is any breaking changes.