Dependency Injection and Application Lifespan

FastAPI dependencies construct request-scoped values and enforce reusable boundary rules; lifespan owns resources shared for the application process. Good dependency design makes identity, authorization, database sessions, gateways, and cleanup explicit. It does not hide business logic in decorators or create a service locator that can return anything from anywhere.

What will you be able to do?

• distinguish application-, request-, and operation-scoped resources;
• yield dependencies that always clean up;
• compose identity and service dependencies;
• override dependencies in deterministic tests.

How should ownership look?

The HTTP connection pool belongs to the process lifespan. A database session belongs to one request or unit of work. The repository and application service can be composed from the session dependency.

Where should authorization happen?

Authentication dependencies can establish a trusted principal. A reusable dependency may reject a missing organization membership. Resource-specific authorization still belongs near the use case because it needs both the principal and the resource. Avoid trusting organization_id from a header without binding it to verified membership.

How do tests replace infrastructure?

Use fixtures so overrides cannot leak between tests.

Why does this matter in AI-native systems?

One process-level provider client can reuse connections, while every call receives request-scoped identity, tenant, budget, trace, and cancellation context. Never store the current user in a global provider client. Tool execution dependencies must derive authority from trusted server context, not model arguments.

Common mistakes

• Creating a new HTTP client for every model call wastes connections.
• Sharing one database session across requests creates concurrency corruption.
• Performing network calls during module import makes startup unobservable and tests brittle.
• Caching a dependency containing user state leaks identities across requests.
• Business rules spread across dependency functions become difficult to reuse outside HTTP.

AI Pair-Programmer Prompt

Exercise

Create a ticket-service dependency backed by a fake repository. Override it for a test and prove cleanup occurs when the route raises.

Acceptance criteria: repeated tests do not share records, overrides are cleared, and cleanup evidence appears on both success and failure.

Knowledge check

1. Which scope owns a database session?
2. Why reuse a provider HTTP client?
3. Can a model-provided tenant ID establish authority?

---

Answers

1. A request or explicit unit of work.
2. To reuse connection pools and centralize timeouts while keeping request state separate.
3. No; authority comes from authenticated server context and verified membership.

Completion checklist

• Every resource has an owner and cleanup path.
• Tests override ports without infrastructure.
• No global value contains current-user state.

Primary references

• FastAPI dependencies
• FastAPI lifespan