Description
PR #583 changed the order or registering configuration sources so that environment variables will be registered before command line arguments. This change fixed issues where the environment variables were overriding the command line argument values (ex: port number for GRPC communication) and that causes worker failing to start.
Looks like this issue was impacting our Linux use cases.
Azure/azure-functions-host#7555
#524
The fix was made to the worker code. But this does not prevent the issue completely because customer can add environment variables as a configuration source after the "ConfigureFunctionsWorkerDefaults" method call in the worker main code.
var host = new HostBuilder()
.ConfigureFunctionsWorkerDefaults()
.ConfigureAppConfiguration(builder => builder.AddEnvironmentVariables())
.Build();
This code causes worker to fail when trying to GRPC handshake. (in Linux + VNet use case)
The workaround is to swap the order as below
var host = new HostBuilder()
.ConfigureAppConfiguration(builder => builder.AddEnvironmentVariables())
.ConfigureFunctionsWorkerDefaults()
.Build();
#1500 is an issue where customers ran into this situation.
There were few ideas discussed in the hallway conversations, updating the worker code to check for command line arguments with FUNC prefix (Ex: FUNCTIONS_GRPC_PORT
) and use that value if present, else fallback to existing implementation (using PORT
argument). Another approach is to pass this information worker needs via environment arguments.