`setup_di` refuses an app whose broker is created in an `on_startup` hook

[lesnik512]

Suggested labels: enhancement

What

setup_di starts with:

if not app.broker:
    msg = "Broker must be defined to setup DI"
    raise RuntimeError(msg)

FastStream supports creating the broker inside a startup hook and attaching it with app.add_broker; its own docstring for the deprecated set_broker calls this out as the intended use ("Useful then you create/init broker in on_startup hook"). An app built that way has no broker when setup_di is called at import time, so the guard rejects it. The only workaround is calling setup_di from inside that same hook, which works because FastStream iterates the hook list by index and picks up the hooks setup_di appends mid-iteration. That is an accident, not a contract.

Since #52 the middleware is installed by an on_startup hook, so the guard is no longer needed for correctness: the broker list is read at startup, not at setup_di time. FastStream itself asserts on an empty broker list right after the startup hooks (_start_broker).

Why it is not just a one-line fix

Startup hooks run in registration order. Dropping the guard covers a broker-creating hook registered before setup_di. In the natural order, setup_di right after constructing the app and hooks defined below it, our install hook runs first, misses the broker, and the first message raises the #55 RuntimeError telling the user to call setup_di, which they did. Installing later is not an option: brokers start consuming right after the startup hooks, and after_startup runs after that.

ADR-0002 kept the guard for exactly this reason and deferred the decision here.

Options

1. Drop the guard, document the order — setup_di must be called after registering any startup hook that adds a broker. Cheapest; leaves the misleading message-time error for the other order.
2. Drop the guard and make the message-time error name this case — extend the fix: name setup_di and app startup when FromDI finds no request container #55 message: the middleware is also missing when the broker was added by a startup hook registered after setup_di. Covers both orders with a correct error, still message-time.
3. Drop the guard and check the broker list at startup — the install hook raises when app.brokers is empty when it runs, naming both remedies. Turns the "hook registered after setup_di" order into a setup-time error again, except when another broker already exists, where (2) still applies.
4. Keep the guard — the documented shape is a broker passed to FastStream(...); the workaround above exists.

Whichever is chosen, the test wants an app constructed with no broker, a startup hook that calls app.add_broker, and a FromDI subscriber on that broker resolving under TestApp. With (3), a second test for the empty list at startup.

Revisit trigger

A user reports the guard blocking a startup-created broker, or FastStream adds a hook for a broker being added to an app (ADR-0002's own revisit trigger, which would make the ordering question moot), or the README grows a startup-created-broker example.