[placeholder] Specialize language worker if worker runtime is not set

[pragnagopa]

For specializing a language worker that is started in placeholder mode, functions host relies on FUNCTIONS_WORKER_RUNTIME to figure out the language for an app. If this app setting is not set, language worker is not specialized.

All the tooling has been updated to set this app setting. We need handle apps that are deployed via ARM and do not set this app setting. Either

• Disable placeholders for such apps or
• Specialize language worker after functions get indexed.

[jeffhollan]

Do you have a sense for priority here? I reviewed a case where this popped up and they were able to mitigate, but this was a case where placeholders impacted an already deployed site. I'm guessing now most people impacted by this would be people potentially trying to use an ARM template that they haven't set this setting right for and would break outright? Trying to feel if this is a "backlog" or P2 or P1

[jeffhollan]

Actually I suppose this may come into play more once we light up MORE placeholders (e.g. JavaScript)

[pragnagopa]

We rely on FUNCTIONS_WORKER_RUNTIME to be set for placeholders to work. Labeling as P2 because all the tooling has been adding worker runtime for a while. Only Apps that would be impacted are the ones which were deployed using ARM and miss setting worker runtime or any apps moving from V1 to V2. In both cases, it is best to let customers set the AppSetting to take advantage of placeholders.

[pragnagopa]

I have redesigned specialization code to take hard dependency on FUNCTIONS_WORKER_RUNTIME if it is not set, apps will go through regular cold start and will work as expected. This will avoid breaking existing apps if runtime is not set.

[pragnagopa]

@mhoeger - Please check if this is still an issue for node placeholders