You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
#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.
The text was updated successfully, but these errors were encountered:
With proper IConfiguration and IOptions usage, we can make the cmd line or environment variable approaches both work and be completely interchangeable. Infact, the root cause is less what mechanism we use to get the values into functions, and more that we used very generic values. If we switch to FUNCTIONS__HOST__URI or FUNCTIONS__GRPC__URI, then these automatically map into IConfiguration as "functions:host:uri" and "functions:grpc:uri". We then have enough insolation on those variables to avoid collisions - which is what was happening. As "HOST" and "PORT" are very generic env vars that are much more likely to already be set.
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.
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
#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 (usingPORT
argument). Another approach is to pass this information worker needs via environment arguments.The text was updated successfully, but these errors were encountered: