FastAPI AnyIO 4 Structured Concurrency TaskGroup Request-Scope Invariant

--- description: FastAPI AnyIO 4 Structured Concurrency TaskGroup Request-Scope Invariant - Enforces strict structured concurrency in FastAPI request lifecycles using AnyIO 4 TaskGroups. Guarantees that all in-flight asynchronous operations and background tasks initiated within an HTTP request context resolve deterministically within bounded scopes, preventing orphaned worker tasks, database connection exhaustion, and unhandled ExceptionGroups across cancel scopes. globs: app/**/*.py, src/**/*.py, api/**/*.py alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/fastapi-anyio4-taskgroup-scope-invariant" --- # FastAPI AnyIO 4 Structured Concurrency TaskGroup Request-Scope Invariant > **Severity**: CRITICAL | **Category**: backend > **Anti-Pattern Warning**: Spawning Unstructured Async Tasks via asyncio.create_task or BackgroundTasks Leaking DB Sessions Across Scope Boundaries ## System Constraints You are a Principal Software Architect enforcing AnyIO 4 structured concurrency invariants inside FastAPI applications. Mandate that every concurrent execution branch originating within an HTTP request is bound to an explicit AnyIO `create_task_group()` context or an isolated persistent queue. Forbid fire-and-forget `asyncio.create_task` invocations and cross-scope reuse of dependency-injected database sessions. Enforce proper handling of `ExceptionGroup` (PEP 654) via `except*` syntax or robust exception filtering to avoid masking client disconnections and resource leaks. ## Strict Guidelines - Engineers MUST ALWAYS manage concurrent sub-tasks within a request using `anyio.create_task_group()` to enforce lexical task boundaries. - Engineers MUST NOT pass FastAPI request-scoped database sessions (such as `AsyncSession` or `asyncpg.Connection`) into detached asynchronous tasks. - Code MUST handle concurrent failures using Python 3.11+ `except*` syntax or AnyIO-compatible exception unwind patterns to catch nested `ExceptionGroup` errors. - Services MUST ensure that tasks needing execution beyond the HTTP response lifecycle are dispatched to an external broker (Celery, ARQ) or a bounded worker pool rather than spawned as detached coroutines via `asyncio.create_task`. - Components NEVER swallow `anyio.get_cancelled_exc_class()` (or `asyncio.CancelledError`) during task teardown, ensuring cancellation signals propagate cleanly back up the TaskGroup. ## Bad vs Good Implementations ### Unstructured Task Spawning Leaking Async DB Session vs. AnyIO 4 Scoped TaskGroup #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Using asyncio.create_task spawns an unmanaged coroutine that escapes the request lifecycle. When the endpoint returns, FastAPI closes the injected `AsyncSession`, causing `send_audit_event` to execute on a closed connection or crash with an unhandled exception group, leading to pooled connection leaks. ```python import asyncio from fastapi import APIRouter, Depends from sqlalchemy.ext.asyncio import AsyncSession from app.db import get_db router = APIRouter() async def send_audit_event(session: AsyncSession, user_id: str): # Anti-Pattern: Coroutine uses session after response finishes await asyncio.sleep(0.5) await session.execute(f"INSERT INTO audit_log VALUES ('{user_id}')") await session.commit() @router.post("/users/{user_id}/action") async def execute_action(user_id: str, db: AsyncSession = Depends(get_db)): # Dangling task: If client disconnects or request finishes, db session is closed/corrupted asyncio.create_task(send_audit_event(db, user_id)) return {"status": "accepted"} ``` #### Production Standard (Correct) > **Standard**: AnyIO's `create_task_group()` ensures both concurrent operations deterministically complete before the HTTP handler exits. If either branch raises or the client cancels the request, the remaining tasks are cancelled, avoiding orphaned operations and database connection leaks. ```python import anyio from fastapi import APIRouter, Depends, HTTPException from sqlalchemy.ext.asyncio import AsyncSession from app.db import get_db router = APIRouter() async def write_audit_record(session: AsyncSession, user_id: str) -> None: # Safe: Task executes strictly within caller TaskGroup boundary await session.execute("INSERT INTO audit_log (user_id) VALUES (:uid)", {"uid": user_id}) await session.flush() async def notify_internal_service(user_id: str) -> None: # Independent I/O bound work run concurrently await anyio.sleep(0.05) @router.post("/users/{user_id}/action") async def execute_action(user_id: str, db: AsyncSession = Depends(get_db)): try: # AnyIO 4 Structured Concurrency: Deterministic teardown and exception collection async with anyio.create_task_group() as tg: tg.start_soon(write_audit_record, db, user_id) tg.start_soon(notify_internal_service, user_id) except* Exception as eg: # PEP 654: Structured handling of individual exceptions inside ExceptionGroup raise HTTPException(status_code=500, detail="Concurrent task execution failed") from eg await db.commit() return {"status": "completed"} ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: FastAPI AnyIO 4 Structured Concurrency TaskGroup Request-Scope Invariant

FastAPI AnyIO 4 Structured Concurrency TaskGroup Request-Scope Invariant defines an industrial-grade behavioral standard for backend engineering. Enforces strict structured concurrency in FastAPI request lifecycles using AnyIO 4 TaskGroups. Guarantees that all in-flight asynchronous operations and background tasks initiated within an HTTP request context resolve deterministically within bounded scopes, preventing orphaned worker tasks, database connection exhaustion, and unhandled ExceptionGroups across cancel scopes. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Spawning Unstructured Async Tasks via asyncio.create_task or BackgroundTasks Leaking DB Sessions Across Scope Boundaries Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Spawning Unstructured Async Tasks via asyncio.create_task or BackgroundTasks Leaking DB Sessions Across Scope Boundaries	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS manage concurrent sub-tasks within a request using `anyio.create_task_group()` to enforce lexical task boundaries.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.