Azure Functions Flex Consumption Python 3.12: successful deployment but zero functions register

Question

Azure Functions Flex Consumption Python 3.12: successful deployment but zero functions register

Mark Green 0

We have a Python 3.12 Azure Functions Flex Consumption application in UK South in a non-production development environment. Azure One Deploy with remote build completes successfully, but the Function host subsequently reports zero functions found/loaded and maps no HTTP routes.

The failure reproduces with two materially different packages:

The reviewed full application, containing seven Python v2 HTTP functions. Local Python 3.12 discovery finds all seven functions.
A deterministic three-file canary containing only function_app.py, host.json and requirements.txt, with one anonymous HTTP function and azure-functions as its only dependency. Local Python 3.12 discovery finds the function and direct invocation returns HTTP 200.

For both packages, Azure reports the remote build/deployment as complete, trigger synchronisation is requested, but the platform registers zero functions and every route returns 404. We also reapplied the existing Python 3.12 runtime and repeated the checks, with the same result.

We inspected the Azure-built full package and confirmed that the required files are at archive root, dependencies are present, and every reviewed source file matches byte-for-byte. Application Insights repeatedly records zero functions found/loaded, no job functions found and no HTTP routes mapped, with no application exception.

The Function App is stopped and there is no production impact or data loss. The issue blocks development integration and TEST/UAT.

This appears to require platform-side inspection of package activation/mount, Python worker startup/indexing, host storage access and trigger synchronisation. Please escalate this to a private Azure support ticket so we can securely provide the subscription, resource, deployment identifiers and sanitised diagnostic evidence bundle. We will not post customer-specific identifiers or diagnostic attachments publicly.

Mark Green 0 Reputation points

2026-08-13T07:27:48.24+00:00

@Pravallika KV Thank you. We have completed the suggested isolation: the application settings were reviewed without changing values; deployment-storage configuration and managed-identity access were verified; the Azure-built full package was inspected and matches the reviewed source byte-for-byte with dependencies present; host telemetry repeatedly reports zero functions and no routes; Python 3.12 was reapplied; and both the seven-function package and a three-file anonymous canary were deployed using One Deploy remote build followed by trigger synchronisation. Both still produce zero indexed functions and 404 responses. The Function remains stopped. Please escalate this PCS question to a private Azure Functions engineering support ticket. We can securely provide subscription, resource and deployment identifiers, UTC timestamps, logs, diagnostic output and the sanitised evidence pack. Please advise the secure hand-off route; we will not post identifiers publicly.

3 answers

Your answer

Mark Green 0 Reputation points

2026-08-13T07:27:48.24+00:00

@Pravallika KV Thank you. We have completed the suggested isolation: the application settings were reviewed without changing values; deployment-storage configuration and managed-identity access were verified; the Azure-built full package was inspected and matches the reviewed source byte-for-byte with dependencies present; host telemetry repeatedly reports zero functions and no routes; Python 3.12 was reapplied; and both the seven-function package and a three-file anonymous canary were deployed using One Deploy remote build followed by trigger synchronisation. Both still produce zero indexed functions and 404 responses. The Function remains stopped. Please escalate this PCS question to a private Azure Functions engineering support ticket. We can securely provide subscription, resource and deployment identifiers, UTC timestamps, logs, diagnostic output and the sanitised evidence pack. Please advise the secure hand-off route; we will not post identifiers publicly.

Answer 1

Hi @Mark Green ,

Thanks for reaching out to Microsoft Q&A.

Update:

We have completed our investigation and identified the root cause.

The deployment and package mounting completed successfully. The issue occurs during Python v2 function indexing because the HTTP trigger parameter name in the function definition does not match the binding name defined by the decorator.

The affected function uses _ as the parameter, while the @app.route decorator defaults to req. This causes the Python worker to reject the function with:

FunctionLoadError: ... parameters ... {'_'}

As Python v2 indexing is all-or-nothing, this causes all functions to be discarded, resulting in “No job functions found” and HTTP 404 responses.

Recommended fix: Rename the parameter to req:

R

@app.route(route="health", auth_level=func.AuthLevel.ANONYMOUS)
def health(req: func.HttpRequest) -> func.HttpResponse:
    return func.HttpResponse("ok")

Alternatively, explicitly set trigger_arg_name="_" in the decorator.

Please also review the remaining functions for similar parameter/binding mismatches before redeploying. Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator

2026-08-31T01:11:49.4833333+00:00

@Mark Green ,If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

Hello @Mark Green

Since you've reproduced the same behavior with a minimal canary containing only function_app.py, host.json, requirements.txt, and azure-functions, I agree this is unlikely to be caused by application-level bindings or dependencies.

One important point for Flex Consumption is that One Deploy is the only supported deployment technology. For Python, Microsoft also recommends packaging from the project root and using remote build.

I would check Diagnose and solve problems → Flex Consumption Deployment in the Function App. Microsoft specifically provides this diagnostic for Flex Consumption and it can show deployment history, package status, and deployment-storage problems.

I would also verify the configured deployment storage and its authentication:

az functionapp config appsettings list \
  --name <function-app> \
  --resource-group <resource-group>

and confirm the Function App can access the deployment storage container. Flex Consumption executes the deployed application from the package stored in that deployment container, so a successful build/upload doesn't necessarily prove that the host subsequently mounted and indexed the expected package.

For one controlled test, I'd also deploy the minimal canary using the documented Core Tools path:

func azure functionapp publish <APP_NAME>

or the documented CLI remote-build path:

az functionapp deployment source config-zip \
  --src <PACKAGE.zip> \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --build-remote true

Microsoft documents both for Python Flex Consumption deployments.

If that still results in deployment succeeded → trigger sync completed → zero functions indexed, especially with the minimal canary, I think you've isolated this sufficiently for Azure Functions engineering review rather than further application troubleshooting.

At that point, the deployment ID, UTC timestamp, Function host logs and sanitized output from the Flex Consumption Deployment diagnostic would be the most useful evidence for escalation.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Mark Green 0 Reputation points

2026-08-13T07:52:17.3266667+00:00

@Allan Solomon Mejia Thank you. We have now run the Flex Consumption Deployment detector over the failed minimal canary. It reports the deployment completed successfully with no warnings or exceptions: Python 3.12 remote build, package upload, worker reset and SyncTriggers all completed, with SyncTriggers returning OK. Separate checks found no app-setting, Key Vault reference, RunOnStartup or hostname issue; deployment storage uses private blob storage with system-assigned identity and the required storage data roles. The canary was published using the documented az functionapp deployment source config-zip --build-remote true path. ARM still reports zero registered functions. This satisfies the isolation you described. Please help escalate this to Azure Functions engineering via a private support ticket; we can provide the identifiers, timestamps, logs and sanitised detector output securely.
Allan Solomon Mejia 8,000 Reputation points

2026-08-15T19:28:48.0533333+00:00

Hello @Mark Green since a Microsoft Moderator is already engaged, I'll let this case be handled by her. She will forward your concern to the appropriate resolver group.

Please let me know if you need any further assistance. Otherwise, if the information provided has resolved your issue, please consider clicking “Accept Answer” to help others who may encounter the same problem.

Thank you!
Allan Solomon Mejia 8,000 Reputation points

2026-08-31T02:12:58.7633333+00:00

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.

Answer 3

Hi @Mark Green ,

A very similar case on this tag last week — 5969167— ended up being app‑side: the entry point was named main.py instead of function_app.py. Not your issue, since your canary already uses the right filename. He also linked #1808 as the same symptom with the correct filename, but that one’s closed with “needs author feedback,” from November 2025 on Python 3.11 — nothing much useful there.

What hasn't been varied is the environment. Both suggestions so far changed the deployment mechanism, and you've done that twice. Three cheap tests:

Try another region — you've only tested UK South
Try Python 3.11 instead of 3.12
Spin up a brand‑new Function App with its own storage account

If the canary works elsewhere, that points to a regional issue and gives you a much sharper support ticket. If it fails everywhere, that’s stronger evidence than a single environment.

For the support ticket: Azure portal → Help + support -> Create a support request