LiteLLMへのコントリビューション体験記：Issue報告からPR作成まで
OSSを利用していると、予期せぬ挙動やバグに遭遇することがあります。その際、Issue（課題）として報告するだけでも十分な貢献ですが、さらに踏み込んでPR（プルリクエスト）を作成することは、エンジニアとして非常に有意義な経験になります。
今回は、LLMプロキシサーバーである LiteLLM において、2つの異なるアプローチで貢献した体験（PR作成とIssue報告）を共有します。
「OSSへのPR作成はハードルが高い」と感じている方の参考になれば幸いです。
Case 1: PRまで作成してマージされた事例
Prismaマイグレーションの判定ロジック修正
まずは、実際にコードを書き、テストを追加してPRを出した事例です。
遭遇した問題
LiteLLMで USE_PRISMA_MIGRATE=True を設定し、PostgreSQL環境で起動した際に、以下の問題が発生していました。
- DBユーザーの権限不足により、マイグレーション実行時にエラー（コード: 42501）が発生。
- しかし、LiteLLM側がそのエラーを「マイグレーションは既に適用済みである」と誤って解釈。
- 結果、テーブルが作成されていないのにアプリケーションが起動し、後の処理でランタイムエラーが発生する。
修正のアプローチ
原因は、Prismaのエラーコード P3018 を検知した際、エラーメッセージの中身を確認せずに一律で「成功」とみなしていた点でした。そこで以下の修正を行いました。
- 権限エラーの検出: エラーメッセージを解析し、権限不足の場合は明確に例外（RuntimeError）を発生させて処理を中断する。
- 冪等性エラーの許容: "already exists" などのメッセージが含まれる場合は、従来どおり「適用済み」として処理を続行する。
コントリビューションのプロセス
プロジェクトの CONTRIBUTING.md のガイドラインに沿って、修正コードに加えて検証用のテストコード（17ケース）を実装し、PRを作成しました。
結果として、レビュワーにとっても検証しやすい状態となり、スムーズにマージされました。
- Issue: #14596
- PR: Fix: Distinguish permission errors from idempotent errors in Prisma migrations #17064
Case 2: Issue報告のみを行った事例
S3ログ出力時の循環参照エラー
次に、Issue報告のみを行いましたが、OSSコミュニティの力強さを実感した事例です。
遭遇した問題
LiteLLMで「S3へのログ保存」と「Bedrock Guardrails」を併用した際、以下のエラーが発生してログ保存に失敗しました。
Error uploading to s3: Circular reference detected
原因調査
ソースコードを追ったところ、以下のことが判明しました。
- Bedrock Guardrails が返すメタデータ内に、自己参照を含む構造が存在する。
- LiteLLMのS3アップロード処理で使用している標準の
json.dumps()が、循環参照に対応できずに落ちている。 - LiteLLM内には既に循環参照対策済みの
safe_dumps()というユーティリティがあるが、この箇所では使われていなかった。
Issue作成と爆速対応
今回はコード修正までは行わず、調査内容をまとめてIssueを作成しました。
Issueには「再現手順」「発生箇所」「原因（safe_dumpsへの置換漏れであること）」を詳細に記載しました。
すると驚くべきことに、Issue作成から約30分後にはメンテナーからPRが出され、翌週にはマージされました。
- Issue: #12731
まとめ
OSSへの貢献は、Issue報告だけでも十分に価値があります。しかし、プロジェクトのルールに従ってテストを書き修正することはエンジニアとして成長することができると思います。
もしOSSでバグを見つけたら、まずは恐れずにIssueを立ててみてください。そしてもし可能なら、その先のPR作成にもチャレンジしてみてください。
Discussion