Fallback behavior to ensure in-proc payload compatibility with dotnet-isolated as the FUNCTIONS_WORKER_RUNTIME value

[kshyju]

This update addresses the issue of running a function app where the FUNCTIONS_WORKER_RUNTIME setting does not match the function metadata from the deployed code. For example, if a function app is configured with "dotnet-isolated" as the FUNCTIONS_WORKER_RUNTIME but has an in-process (in-proc) app payload deployed, this scenario previously worked in version 4.34.

However, in version 4.35, a change was introduced (see this PR) that restricts the use of the dotnet-isolated worker configuration to only when the app is running in placeholder mode. This change was intentional to ensure that FunctionsNetHost starts only in placeholder mode. However, it inadvertently caused issues for incorrectly configured apps (i.e., those with an in-proc payload and a "dotnet-isolated" FUNCTIONS_WORKER_RUNTIME value), as this new behavior prevents the creation of the worker configuration instance, thereby stopping the function app from running.

This PR includes changes to temporarily support this use case while also emitting a diagnostic warning to customers. The intention is to remove this support in a future release.

Why it works in 4.34

The reason it works in 4.34 is we update the "Language" property of function metadata to "dotnet-isolated" (the language present in the workerconfig instance). Code here and here). Having this change (Language in function metadata entries matching with FUNCTIONS_WORKER_RUNTIME
) and having at least one workerconfig instance to match the worker runtime value (dotnet-isolated) make things works.

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

• Backporting to the in-proc branch is not required
  • Otherwise: Link to backporting PR - [in-proc backport] Fallback behavior to ensure in-proc payload compatibility with dotnet-isolated as the FUNCTIONS_WORKER_RUNTIME value #10439 #10449
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • [x ] Otherwise: Backport tracked by issue/PR #issue_or_pr - will follow
• My changes do not require diagnostic events changes
  • Otherwise: Added diag event. will work on docs change.
• I have added all required tests (Unit tests, E2E tests)

Additional information

Additional PR information