Proxy code in V4 is not exercised during placeholder mode causing cold start to increase for apps which opt into proxy for V4

[safihamid]

Warmup Function that gets called during placeholder mode has a proxies.json file that gets processed during placeholder mode in V3. File is present here: https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script.WebHost/Resources/Functions/proxies.json

This file doesn't get processed in placeholder mode because of this logic: https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script/Host/ProxyFunctionProvider.cs#L42

CC @fabiocav , @mgravell

[mgravell]

@safihamid @fabiocav I don't know enough about place-holder mode to understand the impact here; the reason that the environment check was added was to ensure that proxies.json files that exist but aren't currently processed in v4 don't accidentally / unexpectedly change the behaviour; it was considered preferable to make the v4 proxy behaviour opt-in, even if this makes migration from v3 slightly trickier

So: is there a high-level description of placeholder mode? presumably what we should be doing here is ensuring that the feature-flags passed to placeholder-mode are representative of the feature-flags passed to the primary executable. However, I don't know how placeholder-mode is launched, to look into how to do this.

---

Thinking of alternative solutions: an alternative opt-in mechanism we discussed was to look for a few flag in the proxies.json file itself (think "proxiesEnabled": "true" or similar) - such that proxies.json is only processed if that flag is found. This would presumably work here, since the file is (I guess?) the same proxies.json file in placeholder mode? However, the environmental feature-flags test was preferred