01
Confirm the programming model and entry module
This diagnosis applies to the Python v2 decorator model. Check the intended function_app.py, its global FunctionApp object, and the modules it imports. A v1 function.json layout follows a different discovery contract.
In the local example, the route existed inside a Blueprint object. A separate empty FunctionApp still had no registered functions. Merely importing the module or seeing its decorator in source did not attach its functions to that app.
02
Keep the Blueprint definition explicit
The routes module below defines one local demonstration route. Its anonymous authentication level is for this small test; select the intended authentication policy for a real deployment. The important object is the exported Blueprint instance.
Avoid creating a second unrelated FunctionApp in the routes module when the entry module is expected to collect Blueprints. Make it clear which object owns the decorators and which app receives the registration.
# routes.py — minimal local demonstration
import azure.functions as func
bp = func.Blueprint()
@bp.route(route="proof", auth_level=func.AuthLevel.ANONYMOUS)
def proof(req: func.HttpRequest) -> func.HttpResponse:
return func.HttpResponse("blueprint-ok")03
Register the intended Blueprint on the indexed app
Import the exported instance and register it on the entry module’s FunctionApp. Keep registration deterministic and avoid importing the same functions through multiple paths. Duplicate names or circular imports can produce different discovery failures.
The following entry module illustrates the tested relationship. The routes.py file must be included in the delivered project and importable from that deployment layout.
# function_app.py
import azure.functions as func
from routes import bp
app = func.FunctionApp()
app.register_functions(bp)04
Inspect metadata and exercise the local handler
The SDK registration API can reveal whether functions were attached before you investigate cloud routing. In the lab, the empty app contributed zero functions; after registration it exposed one. A direct call to that registered handler returned blueprint-ok.
This check proves the Python object graph and handler behavior. It does not start the Functions host or prove successful host indexing, trigger configuration, deployment packaging, or authorization in Azure.
# Local registration check after importing the intended entry module:
from function_app import app
functions = app.get_functions()
assert len(functions) == 1 # This minimal demo has exactly one function.05
Verify the delivered host’s view next
Run the application through the intended local Functions tooling and inspect host startup/indexing output. Then deliver through the normal workflow and verify the selected deployment and route. The SDK check should narrow the problem, not replace that integration step.
If registration succeeds but the host still lists no functions, continue with import errors, dependencies, deployed files, runtime settings, and the actual entry module. Preserve the new evidence instead of repeatedly adding registrations to unrelated app instances.
Know the limits
Validated with azure-functions 1.25.0. An unregistered Blueprint contributed zero functions to the app; registration exposed one and a direct handler call returned the expected body. The Azure Functions host, bindings infrastructure, and cloud deployment were not executed.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles