Azure-functions-host: v2 Azure Functions Proxy Cold Start Issue

[JamesRandall]

Investigative information

• Timestamp: 16:00 GMT 3rd July 2018
• Function App version (1.0 or 2.0-beta): 2.0.11888.0-beta1
• Function App name:
• Function name(s) (as appropriate): OpenAPIUI2 (its a proxy)
• Invocation ID: not sure how I get this for a proxy
• Region: UK South

Repro steps

I have a set of proxies that point to a single function. This function (OpenApiProvider) reads an asset from the assembly as a manifest resource stream and returns it setting the appropriate content type.

To repro this you need to be in a cold start situation - so let the app idle for a while or restart. And then call the proxy. The endpoints that are failing are all JavaScript files and end in a .js extension but that could be luck of the draw so to speak.

Expected behavior

It should return the requested file at the endpoint the proxy is hosted on.

Actual behavior

All works fine both locally and on Azure _except_ when the Function App is cold starting. If I leave it to idle or restart it fairly often the proxy will fail on its first call. Not always but over 50% of the time. If I then call it again it works fine. The client receives an Internal Server 500 error and the backing function is never called.

Looking at the logs that are output (I used Streaming Logs as a quick way of getting insight) it looks like the proxy is not being seen as a proxy at that point but instead is being handled as a file request by IIS - I get a length HTML type formatted error coming back and in the middle of it is this block here:

`

Requested URL	https://apifn-dev-nq6svtv7atihu:80/openapi/swagger-ui-standalone-preset.js.map
Physical Path	D:\Program Files (x86)\SiteExtensions\Functions\2.0.11888-alpha\openapi\swagger-ui-standalone-preset.js.map
Logon Method	Anonymous
Logon User	Anonymous

`

Known workarounds

None!

Related information

Code is all open source if you want to see it.

[safihamid]

@JamesRandall thanks for reporting this issue. where is the open source code that we can take a look and try to repro? Also do you get this both locally and on Azure?

[JamesRandall]

Thanks for getting back to me.

It only occurs in Azure itself. The code is a little bit convoluted to look at as it comes from my Function Monkey library - this uses Roslyn to compile Function assemblies and proxies from templates. Though thankfully in this case their is little input parameterisation of the template so its still pretty easy to read:

https://github.com/JamesRandall/FunctionMonkey/blob/master/Source/FunctionMonkey.Compiler/Templates/swaggerui.csharp.handlebars

An example of a proxy definition that goes wrong is:

"OpenAPIUI2": {"matchCondition":{"route":"/openapi/swagger-ui-bundle.dodge.js","methods":["GET"]},"backendUri":"https://localhost/api/OpenApiProvider?name=swagger-ui-bundle.dodge.js"}

The .dodge bit was me trying things to resolve it - I wandered if their was something special about Swagger files in terms of them being "reserved names" in some way. Originally I was using a wildcard proxy - I moved to specific proxies again as part of trying to resolve things. It didn't help.

These proxies are all used to expose a Swagger UI from a generated openapi.yaml file and so the sequence that triggers the error is to open the UI (a proxy itself on index.html) and it then calls for its assets and this is when it goes wrong.

I've got an example deployed in Azure that you could look at if helpful just don't want to disclose the names on here (its all pre-launch).

[safihamid]

@vfedonkin would you please look into this?

[vfedonkin]

Sure, I'm on vacation now but will look next week

[JamesRandall]

Thanks both. If you want any more info / want to screen share / or Azure details just let me know.

[vfedonkin]

I could repro the issue.

The scenario is:

1. create functions app V2.
2. create any JS function (just use default values).
3. create proxy having that function as a backend.
4. restart the function app. wait 30 - 40 seconds.
5. call proxy. 500 is returned.

Investigating.

[safihamid]

Thanks @vfedonkin for the repro and @JamesRandall for bringing this bug to our attention. @mathewc is going to fix this issue soon and we just realized our test for this scenario was disabled for v2. going to enable the test as well to make sure it doesn't repro in future.

[JamesRandall]

Great! Glad to be able to help.