【要約】FastAPIのDIでyieldが自動で実行される仕組み [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
FastAPIで `yield` を用いたDI（例：DBセッション管理）を利用する際、`yield` 以降の処理（後処理）を呼び出す明示的なコードがどこにも記述されていない。このため、リソースの解放がどのようなトリガーで、どのような仕組みによって保証されているのか、その内部的な実行メカニズムが不明瞭であるという課題がある。
// Approach
Pythonの `with` 文によるコンテキスト管理の仕組みをベースに、`contextlib.contextmanager` デコレータがジェネレータ関数をどのようにコンテキストマネージャとして扱うかを分析。FastAPIが内部的にこの仕組みを利用し、リクエストのライフサイクルに合わせて `yield` 前後の処理を制御していることを論理的に導き出している。
// Result
`yield` を用いたDIは、内部的に `with` 文の挙動を模倣することで、リクエスト終了時に確実に後処理を実行できることが判明した。一方で、`contextmanager` の制約により、`yield` が複数存在する場合は `RuntimeError` が発生するという技術的限界も確認された。これにより、DI設計における注意点が明確化された。
Senior Engineer Insight
> FastAPIにおけるリソース管理の根幹を突いた内容だ。DB接続のような、クローズ漏れが致命的な障害に直結する領域において、`yield` を用いたDIは極めて実戦的なパターンである。`contextlib.contextmanager` の挙動を理解することは、単なる構文の理解に留まらず、リクエストのライフサイクルとリソースの生存期間を制御する設計能力に直結する。ただし、`yield` が複数ある場合に `RuntimeError` を吐くという制約は、複雑な依存関係を組む際に設計ミスを誘発するリスクがある。便利さに甘んじず、言語仕様の制約を把握した上で、堅牢なエラーハンドリングを組み込むことがプロの仕事だ。