Azure-functions-host: listFunctions ARM api fails for linux consumption function app

[ejizba]

Recently noticed the structure for linux is different for windows again (first happened here: https://github.com/Azure/azure-functions-host/issues/3502), causing problems when listing functions in the VS Code extension. Also the linux one doesn't have an "id" property

Here is what we get on linux consumption:

[
    {
        "name": "HttpTrigger",
        "script_root_path_href": "https://emjpy3.azurewebsites.net/admin/vfs/home/site/wwwroot/HttpTrigger/",
        "script_href": "https://emjpy3.azurewebsites.net/admin/vfs/home/site/wwwroot/HttpTrigger/__init__.py",
        "config_href": "https://emjpy3.azurewebsites.net/admin/vfs/home/site/wwwroot/HttpTrigger/function.json",
        "test_data_href": "https://emjpy3.azurewebsites.net/admin/vfs/tmp/FunctionsData/HttpTrigger.dat",
        "href": "https://emjpy3.azurewebsites.net/admin/functions/HttpTrigger",
        "invoke_url_template": "https://emjpy3.azurewebsites.net/api/httptrigger",
        "language": "python",
        "config": {
            "scriptFile": "__init__.py",
            "bindings": [
                {
                    "authLevel": "anonymous",
                    "type": "httpTrigger",
                    "direction": "in",
                    "name": "req",
                    "methods": [
                        "get",
                        "post"
                    ]
                },
                {
                    "type": "http",
                    "direction": "out",
                    "name": "$return"
                }
            ]
        },
        "files": null,
        "test_data": "",
        "isDisabled": false,
        "isDirect": false,
        "isProxy": false
    }
]

Here is what we get on windows:

{
    "value": [
        {
            "id": "/subscriptions/0b88671f-d5c2-45cf-8ee4-60c65fc6eee8/resourceGroups/emjjs1/providers/Microsoft.Web/sites/emjjs1/functions/HttpTrigger",
            "name": "emjjs1/HttpTrigger",
            "type": "Microsoft.Web/sites/functions",
            "location": "West US",
            "properties": {
                "name": "HttpTrigger",
                "function_app_id": "/subscriptions/0b88671f-d5c2-45cf-8ee4-60c65fc6eee8/resourceGroups/emjjs1/providers/Microsoft.Web/sites/emjjs1",
                "script_root_path_href": "https://emjjs1.scm.azurewebsites.net/api/vfs/site/wwwroot/HttpTrigger/",
                "script_href": "https://emjjs1.scm.azurewebsites.net/api/vfs/site/wwwroot/dist/HttpTrigger/index.js",
                "config_href": "https://emjjs1.scm.azurewebsites.net/api/vfs/site/wwwroot/HttpTrigger/function.json",
                "secrets_file_href": "https://emjjs1.scm.azurewebsites.net/api/vfs/data/functions/secrets/HttpTrigger.json",
                "href": "https://emjjs1.scm.azurewebsites.net/api/functions/HttpTrigger",
                "config": {
                    "bindings": [
                        {
                            "authLevel": "function",
                            "type": "httpTrigger",
                            "direction": "in",
                            "name": "req",
                            "route": "test",
                            "methods": [
                                "get",
                                "post"
                            ]
                        },
                        {
                            "type": "http",
                            "direction": "out",
                            "name": "res"
                        }
                    ],
                    "scriptFile": "../dist/HttpTrigger/index.js"
                },
                "files": null,
                "test_data": ""
            }
        }
    ]
}

[fabiocav]

@mathewc is this related to the latest sync triggers change?

[ejizba]

FYI - looking back at our telemetry, I think this issue started happening for us around April 18th

[mathewc]

The ARM updates I made haven't been deployed yet, so are not active. The issue in the payload you shared is that the response isn't ARM wrapped. @ahmelsayed / @balag0 - ARM wrapping is added in your patch branch https://github.com/Azure/azure-functions-host/commits/balag-release in commit https://github.com/Azure/azure-functions-host/commit/be5d186cb85cdedc325d2fa50f6458ef29d62e4a, which you apply as part of Linux Consumption release. The only thing I can think of is that this patch wasn't applied in the latest release? Did we regress the same way we did in https://github.com/Azure/azure-functions-host/issues/3502?

[fabiocav]

@balag0 assigning this to you as you'd need to handle the update.

[ahmelsayed]

The changes were here https://github.com/Azure/azure-functions-host/pull/3704 but I thought that is no longer needed with Mathew's changes. I can pull the commit for adding the ARM envelope from there to the mesh image. but I want to verify with @mathewc that this will not double wrap the response once he enables his feature.

[mathewc]

The ARM changes in ANT 82 won’t be deployed for another few weeks. So the previous wrapping is still needed. That work is also behind a Geo feature flag. No double wrapping will happen - the new API when enabled will remove the header the runtime checks for so runtime won’t wrap. We wrap in the Geo API.

[ahmelsayed]

should be fixed in https://github.com/Azure/azure-functions-docker/commit/8ae116e654065fa3aa88c3ad1de8b360609675dc

[cgillum]

@ahmelsayed I got a CRI for this. When you do think this Docker update will be released?

[ahmelsayed]

@balag0 were you able to push the 2.0.12452 image from HK1 to all the other regions?

[ahmelsayed]

actually I just checked and I see it everywhere. Maybe they just need to retry, if they still see this after restarting their app then please add me on that incident