FastAPI with Blueprints returns "detail: Not Found"

[danielniccoli]

I was following the blueprint sample which I rewrote to use FastAPI.

# function_app.py

import azure.functions as func
import fastapi

from durable_blueprints import bp

fastapi_app = fastapi.FastAPI()
app = func.AsgiFunctionApp(app=fastapi_app, http_auth_level=func.AuthLevel.ANONYMOUS)
app.register_functions(bp)  # register the DF functions


@fastapi_app.get("/HttpTrigger")
async def get_name():
    return { "foo": "bar" }

#durable_blueprint.py

import azure.durable_functions as df
import azure.functions as func

bp = df.Blueprint()


@bp.route(route="startOrchestrator")
@bp.durable_client_input(client_name="client")
async def start_orchestrator(req: func.HttpRequest, client):
    instance_id = await client.start_new("my_orchestrator")
    return client.create_check_status_response(req, instance_id)


@bp.orchestration_trigger(context_name="context")
def my_orchestrator(context: df.DurableOrchestrationContext):
    result1 = yield context.call_activity("say_hello", "Tokyo")
    result2 = yield context.call_activity("say_hello", "Seattle")
    result3 = yield context.call_activity("say_hello", "London")
    return [result1, result2, result3]


@bp.activity_trigger(input_name="city")
def say_hello(city: str) -> str:
    return f"Hello {city}!"

// host.json

{
  "version": "2.0",
  "extensions": {
    "http": {
      "routePrefix": ""
    }
  },
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    }
  },
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  }
}

The host starts successfully

 *  Executing task: .venv\Scripts\activate ; func host start 

Found Python version 3.10.11 (py).

Azure Functions Core Tools
Core Tools Version:       4.0.5198 Commit hash: N/A  (64-bit)
Function Runtime Version: 4.21.1.20667

[2023-08-09T14:17:16.165Z] Worker process started and initialized.

Functions:

        http_app_func: [GET,POST,DELETE,HEAD,PATCH,PUT,OPTIONS] http://localhost:7071//{*route}

        start_orchestrator:  http://localhost:7071/startOrchestrator

        my_orchestrator: orchestrationTrigger

        say_hello: activityTrigger

For detailed output, run func with --verbose flag.

A GET request to http://localhost:7071/HttpTrigger returns {"foo":"bar"} as expected.

A GET request to http://localhost:7071/api/startOrchestrator returns {"detail":"Not Found"}, against my expectation. (Same with ``http://localhost:7071/startOrchestrator`.) I expected the request to start an orchestration.

My ultimate goal is to server both, functions and durable functions from the same project to simplify development. What do I need to change to make this work?

[davidmrdavid]

Hi Daniel Niccoli (@danielniccoli), apologies for the late response. I need a bit more context here: is there a reason why you want to use "FastAPI" instead of a regular HTTP Trigger annotation to serve your Durable Functions?

[danielniccoli]

Simple. FastAPI with Pydantic offer schema creation, input validation, openAPI specs and Swagger UI. Regular HTTP triggers offer none of that and I would have to implement that all manually, which is a ton of work.

[apasha14]

Was this ever answered? I have the same use case. Thanks

[andremarques023]

Hi David Justo (@davidmrdavid), any news here? Will there be support for working with blueprints and FastAPI together?

[AndreRicardo-Zoetis]

Same issue here.

[andystaples]

Thanks everyone for the detailed scenario and feedback. We investigated this against the current Python programming model.

df.Blueprint registration itself is supported by AsgiFunctionApp. The conflict is caused by AsgiFunctionApp registering its HTTP entry point as the catch-all route /{*route}. As a result, requests intended for another HTTP-triggered function, such as startOrchestrator, can be dispatched to FastAPI instead, where FastAPI correctly returns 404 {"detail":"Not Found"}.

The durable Python SDK cannot resolve that route ownership: it is defined by the core azure-functions library. The appropriate platform enhancement is a configurable ASGI/WSGI route prefix so the ASGI app can own, for example, /fastapi/{*route}, while Durable Functions and other HTTP triggers retain their own routes. That work is already represented by Azure/azure-functions-python-library#215.

Until that capability ships, the workaround is to use a normal FunctionApp and explicitly forward only a prefixed catch-all route to AsgiMiddleware, or provide an equivalent custom ExternalHttpFunctionApp. This keeps the FastAPI and Durable starter routes disjoint.

No production change is expected in azure-functions-durable-python once the upstream prefix support is available. We may add an integration test/sample here at that point, but the missing feature is owned upstream. Closing this issue as covered by Azure/azure-functions-python-library#215.