Async generator dependencies in FastAPI - Step-by-Step Execution

Concept Flow - Async generator dependencies

Request received

↓

Call async generator dependency

↓

Yield resource (e.g., DB session)

↓

Use resource in endpoint

↓

After response sent

↓

Run cleanup code after yield

↓

Close resource

↓

Request complete

Shows how FastAPI calls an async generator dependency, yields a resource for use, then runs cleanup after response.

Execution Sample

FastAPI

async def get_db():
    db = create_db_session()
    try:
        yield db
    finally:
        await db.close()

Defines an async generator dependency that yields a DB session and closes it after use.

Execution Table

Step	Action	State Before	State After	Notes
1	Request starts, call get_db()	No DB session	DB session created	DB session object created but not yielded yet
2	Yield DB session	DB session created	DB session yielded	Endpoint receives DB session to use
3	Endpoint uses DB session	DB session yielded	DB session in use	Endpoint runs with DB session
4	Response sent	DB session in use	Response sent	Client gets response
5	Run finally block after yield	Response sent	Closing DB session	Cleanup starts
6	Await db.close()	Closing DB session	DB session closed	DB connection closed
7	Request complete	DB session closed	No active DB session	Dependency cleanup done

💡 Request lifecycle ends after cleanup code runs post-yield

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 5	After Step 6	Final
db	None	DB session created	DB session yielded	DB session yielded (still open)	DB session closing	DB session closed

Key Moments - 3 Insights

Why does the async generator use yield instead of return?

Because FastAPI needs to pause the function to give the resource to the endpoint, then resume after the response to run cleanup. See execution_table steps 2 and 5.

When does the cleanup code after yield run?

It runs after the response is sent to the client, as shown in execution_table step 5, ensuring resources are properly closed.

What happens if the endpoint raises an error while using the yielded resource?

The finally block still runs after yield, so cleanup happens regardless of errors, ensuring no resource leaks.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of 'db' after step 2?

A DB session yielded and ready for use

B DB session closed

C No DB session created yet

D DB session is closing

💡 Hint

Check the 'State After' column for step 2 in execution_table

At which step does the cleanup code start running?

A Step 3

B Step 1

C Step 5

D Step 7

💡 Hint

Look for 'Run finally block after yield' in execution_table

If the endpoint raises an error during DB use, what happens to the cleanup?

A Cleanup code does not run

B Cleanup code runs after response

C DB session stays open

D Request hangs indefinitely

💡 Hint

Refer to key_moments about error handling and finally block

Concept Snapshot

Async generator dependencies in FastAPI:
- Use async def with yield to provide resources
- Yield pauses function, lets endpoint use resource
- After response, code after yield runs for cleanup
- Ensures resources like DB sessions close properly
- Works even if endpoint errors occur

Full Transcript

This visual trace shows how FastAPI handles async generator dependencies. When a request comes in, FastAPI calls the async generator function, which creates a resource like a database session. It then yields this resource to the endpoint function, pausing the generator. The endpoint uses the resource to process the request. After the response is sent to the client, FastAPI resumes the generator to run the cleanup code after the yield, such as closing the database session. This ensures resources are properly managed and closed even if the endpoint raises an error. The variable tracker shows the state of the database session object through each step, from creation to closure. Key moments clarify why yield is used and when cleanup happens. The quiz questions help reinforce understanding by referencing the execution steps and variable states.

Practice

1. What is the main purpose of using an async generator dependency in FastAPI?

easy

A. To manage setup and cleanup actions around a request automatically

B. To speed up synchronous code execution

C. To replace all regular functions with asynchronous ones

D. To create infinite loops inside API endpoints

Solution

1. Step 1: Understand async generator dependencies

   Async generator dependencies use async def with yield to run setup code before yielding and cleanup code after.

2. Step 2: Identify their purpose in FastAPI

   This pattern is mainly used to manage resources safely, like opening and closing database connections around a request.

3. Final Answer:

   To manage setup and cleanup actions around a request automatically -> Option A

4. Quick Check:

   Async generator dependencies = setup + cleanup [OK]

Hint: Think setup before yield, cleanup after yield [OK]

Common Mistakes:

• Confusing async generators with normal async functions
• Thinking they speed up synchronous code
• Assuming they replace all functions

2. Which of the following is the correct syntax to define an async generator dependency in FastAPI?

easy

A. async def resource(): yield 'data'

B. def resource(): yield 'data'

C. async def resource(): return 'data'

D. def resource(): return 'data'

Solution

1. Step 1: Identify async generator syntax

   An async generator uses async def and yield inside the function body.

2. Step 2: Compare options

   async def resource(): yield 'data' uses async def and yield, which is correct. Options A and B are synchronous, and C uses return instead of yield.

3. Final Answer:

   async def resource(): yield 'data' -> Option A

4. Quick Check:

   Async + yield = async generator [OK]

Hint: Async generator = async def + yield inside [OK]

Common Mistakes:

• Using return instead of yield
• Forgetting async keyword
• Using synchronous def for async generator

3. Given this FastAPI async generator dependency, what will be printed when the endpoint is called?

async def resource():
    print('Setup')
    yield 'data'
    print('Cleanup')

@app.get('/')
async def read(resource=Depends(resource)):
    print('Inside endpoint')
    return resource

medium

A. Inside endpoint only

B. Inside endpoint, Setup, Cleanup

C. Setup, Cleanup, Inside endpoint

D. Setup, Inside endpoint, Cleanup

Solution

1. Step 1: Understand async generator flow

   When the endpoint is called, FastAPI runs the async generator up to the yield (prints 'Setup'), then runs the endpoint code (prints 'Inside endpoint'), then after response finishes, runs code after yield (prints 'Cleanup').

2. Step 2: Order of prints

   The prints happen in order: 'Setup', 'Inside endpoint', 'Cleanup'.

3. Final Answer:

   Setup, Inside endpoint, Cleanup -> Option D

4. Quick Check:

   Yield pauses, so Setup before, Cleanup after endpoint [OK]

Hint: Setup prints before yield, cleanup after endpoint runs [OK]

Common Mistakes:

• Assuming cleanup runs before endpoint
• Thinking yield returns immediately
• Ignoring async generator lifecycle

4. Identify the error in this async generator dependency code:

async def resource():
    connection = await connect_db()
    yield connection
    await connection.close()

@app.get('/')
async def read(conn=Depends(resource)):
    return {'status': 'ok'}

medium

A. Missing await before yield

B. Cannot yield inside async def

C. Not using try-finally to ensure cleanup

D. Depends should not be used with async generators

Solution

1. Step 1: Check resource cleanup safety

   Without try-finally, if an exception occurs, await connection.close() might not run, causing resource leaks.

2. Step 2: Proper pattern for async generator cleanup

   Use try-finally around yield to guarantee cleanup runs even on errors.

3. Final Answer:

   Not using try-finally to ensure cleanup -> Option C

4. Quick Check:

   Always use try-finally for cleanup in async generators [OK]

Hint: Use try-finally to guarantee cleanup after yield [OK]

Common Mistakes:

• Forgetting try-finally causes resource leaks
• Thinking yield needs await
• Believing Depends can't use async generators

5. You want to create an async generator dependency that opens a database connection, yields it, and ensures it closes even if the endpoint raises an error. Which code snippet correctly implements this?

hard

A. async def db():
conn = await open_db()
yield conn
await conn.close()

B. async def db():
conn = await open_db()
try:
yield conn
finally:
await conn.close()

C. async def db():
conn = await open_db()
yield conn
conn.close()

D. async def db():
conn = open_db()
yield conn
await conn.close()

Solution

1. Step 1: Ensure proper async resource management

   Opening the connection must be awaited, and closing must happen even if errors occur.

2. Step 2: Use try-finally around yield

   Only async def db(): conn = await open_db() try: yield conn finally: await conn.close() uses try-finally to guarantee await conn.close() runs after yield, even on exceptions.

3. Final Answer:

   async def db(): conn = await open_db() try: yield conn finally: await conn.close() -> Option B

4. Quick Check:

   Try-finally ensures cleanup after yield [OK]

Hint: Wrap yield in try-finally to always close resources [OK]

Common Mistakes:

• Not awaiting open_db()
• Not using try-finally for cleanup
• Calling close() without await