mir-backend-python-fastapilisted
Install: claude install-skill anantbhandarkar/make-it-right
# /mir-backend-python-fastapi · Make It Right (FastAPI)
Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-python` (CPython runtime model) → **this** (FastAPI/SQLAlchemy library mechanics). Run the gates first; load the Python runtime tier for the concurrency/process model; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (GIL, async-vs-sync, blocking the event loop, fork-safe pools, cold start) live in `mir-backend-python` — not here.**
**Stack assumed:** FastAPI · SQLAlchemy 2.0 async (`AsyncSession`, `asyncpg`) · PostgreSQL · Alembic · Redis. If the project uses sync SQLAlchemy or a different DB, note the divergence before applying these.
## The FastAPI footguns AI walks into most
These are the stack-specific cousins of the failure-mode catalog. Each is something async-FastAPI code gets wrong even when the *logic* is right.
### 1. Async session lifecycle — the #1 source of mystery bugs
- **One `AsyncSession` per request, via a `Depends` dependency.** Never a module-level/global session — it's not concurrency-safe and you'll get cross-request data bleed or `InterfaceError`.
- **Never share one session across `asyncio.gather` tasks.** A session is a single connection's unit of work; concurrent use corrupts it. Give each task its own session from the factory.
- **Commit/rollback boundary belongs in the dependency or service, explicitly** — don't rely on autocommit. `expire_on_commit=Fa