Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Add request/response logging hook to native model client

オープン
#503 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@chethanuk がすでに取り組んでいます。

2026年10月6日 から。

  • #983 @chethanuk による — マージされずにクローズ

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
python

調査の方向性

packages/data-designer-engine/src/data_designer/engine/models/clients/ から始めて、ThrottledModelClient、clients/retry.py、clients/types.py を読みます。hook の設計を選ぶ前に、既存の wrapper と transport の構成パターンを比較してください。consumer が prompt、model、kwargs、response body、token usage を含む、同等の request と response の詳細を観測でき、選択したインターフェースの coverage がある状態で issue は完了です。

索引モデルが issue の本文から書いたものです。

説明

enhancement

Priority Level

Medium (Nice to have)

Is your feature request related to a problem? Please describe.

With the migration from litellm to the native model client in DD 0.5.5, there's no built-in way to capture full HTTP request/response payloads for LLM API calls. Previously, litellm's callback system allowed registering custom loggers that could observe every request and response. This was useful for debugging prompt issues, auditing API calls, and troubleshooting generation failures at scale.

Describe the solution you'd like

Expose a hook or callback mechanism on the native model client that allows consumers to observe request/response data. This could be:

  1. httpx event_hooks: The native client uses httpx internally. httpx supports event_hooks={"request": [...], "response": [...]} on the client constructor. Exposing a way to inject these hooks (e.g. via ModelConfig or the ModelClient factory) would let downstream tools register logging callbacks without modifying DD internals.

  2. A dedicated logging transport: An optional httpx transport wrapper that logs request/response bodies before forwarding, similar to how ThrottledModelClient wraps with throttling.

  3. RunConfig option: A debug_log_requests: bool field on RunConfig that enables built-in request/response logging to a configurable path, handled entirely within DD.

Option 1 is the most flexible (consumers control what's logged). Option 3 is the most user-friendly.

Describe alternatives you've considered

  • Keeping litellm as an optional dependency just for debug logging - adds unnecessary dependency weight
  • Monkey-patching the httpx client after DD creates it - fragile and version-dependent
  • Using Python logging at DEBUG level to capture httpx traffic - httpx logs at TRACE level which is very verbose and not structured

Agent Investigation

Explored DD 0.5.5 codebase:

  • Native client lives in packages/data-designer-engine/src/data_designer/engine/models/clients/
  • ThrottledModelClient wraps ModelClient with per-request hooks (throttle acquire/release) - same pattern could wrap with logging
  • clients/retry.py builds httpx RetryTransport - the transport layer is already composable
  • No existing event_hooks, logging hooks, or callback mechanism on the client
  • clients/types.py defines ChatCompletionRequest/Response which contain the structured data that would need to be logged

Additional context

The previous litellm-based logger captured: timestamp, model name, full prompt messages, request kwargs, complete response body, and token usage per API call. Whatever replaces it should capture equivalent data. This is particularly useful when running large-scale generation jobs where individual request failures need to be diagnosed.

Checklist

  • I've reviewed existing issues and the documentation
  • This is a design proposal, not a "please build this" request
主要言語
Python
スター
2.3k
フォーク
227
平均マージ
22時間 13分
マージ済み PR(30日)
63

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NVIDIA-NeMo/DataDesigner のほかの issue

NVIDIA-NeMo/DataDesigner の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。