Resolve Azure Functions Python metadata timeout by matching the decorator's function name and folder

Metadata timeout in a Python Azure Function with HTTP trigger? Align the decorator's name and folder to fix discovery and restore reliable local debugging.

Deploying a first Python Azure Function often feels straightforward until a tiny mismatch in structure stops the runtime from discovering your function. A common symptom is that your code runs when executed directly, but fails when wired behind an HTTP trigger in Azure Functions, showing a metadata timeout during local debugging or deployment.

Repro in a nutshell

The entry point defines an HTTP-triggered function that calls a routine doing SharePoint work. Running the modules separately succeeds. As soon as the HTTP function imports and calls that routine, local debugging reports a timeout and the function isn’t listed by the host.

[2025-04-24T17:18:19.054Z] Requesting metadata from worker failed.
[2025-04-24T17:18:19.057Z] Microsoft.Azure.WebJobs.Script.Grpc: The operation has timed out.

Problematic example

The following shows the shape of the setup that runs fine as plain Python scripts but causes trouble when hosted as an Azure Function.

import azure.functions as azf
import logging
from azure.functions import HttpRequest, HttpResponse
from worker_unit import kickoff
app_host = azf.FunctionApp()
@app_host.function_name(name="Trigger")
@app_host.route(route="myApp", auth_level=azf.AuthLevel.ANONYMOUS)
def http_entry(req: azf.HttpRequest) -> azf.HttpResponse:
    try:
        kickoff()  # Connects to SharePoint, cleans, re-uploads
        return azf.HttpResponse(" process completed successfully.", status_code=200)
    except Exception as err:
        logging.error(f"Error executing  process: {str(err)}")
        return azf.HttpResponse(f"An error occurred: {str(err)}", status_code=500)

When the import and the call to the SharePoint routine are removed, the HTTP function surfaces normally and the URL responds. Adding them back triggers the timeout and the function does not appear under the Functions list.

What’s actually wrong

The function was explicitly named via the decorator as Trigger. With that name in place, the runtime expected the function’s files to live under a folder named Trigger within the Function App. Keeping everything at the project root prevented proper discovery. The host failed to retrieve function metadata and surfaced a generic timeout during startup and debug attach.

The fix

Create a folder named Trigger in the Function App and move the relevant files into it. After aligning the folder and the decorator’s name, the function is discovered and runs as intended.

Here is the same logic placed under the Trigger folder. The HTTP entry point calls the SharePoint workflow routine that sits alongside it.

import azure.functions as azf
import logging
from azure.functions import HttpRequest, HttpResponse
from work_item import run_flow
func_app = azf.FunctionApp()
@func_app.function_name(name="Trigger")
@func_app.route(route="myApp", auth_level=azf.AuthLevel.ANONYMOUS)
def http_main(req: azf.HttpRequest) -> azf.HttpResponse:
    try:
        run_flow()
        return azf.HttpResponse(" process completed successfully.", status_code=200)
    except Exception as exc:
        logging.error(f"Error executing  process: {str(exc)}")
        return azf.HttpResponse(f"An error occurred: {str(exc)}", status_code=500)

The program flow and behavior are unchanged: the HTTP-triggered function invokes the SharePoint routine, and success or failure is returned to the client. The only material change is the placement of the files inside a folder whose name matches the decorator’s function name.

Why this matters

In Python Azure Functions, discovery depends on conventions. When the explicit function name and the on-disk layout do not align, the host can’t load metadata for the function, and debugging tools report a timeout. It looks like a runtime or networking problem, but the root cause is structural. Keeping the folder name aligned with the function name ensures the host finds and loads your function consistently.

Takeaways

When an HTTP-triggered function runs as a script but fails in the Functions host with a metadata timeout, first verify that the function’s explicit name matches the folder that contains its files. Place the entry point and any invoked modules inside that folder. After that, confirm the function appears under Functions locally, hit the route, and proceed with deployment. Small mismatches in structure can lead to outsized confusion; aligning the decorator’s name and folder layout resolves the discovery problem cleanly.