Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Add request/response logging hook to native model client

未关闭
  • 哪里不对？
#503 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@chethanuk 已经在做这个了。

开始于 2026年10月6日。

  • #983 来自 @chethanuk —— 已关闭，未合并

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
python
领域
ai, api, backend-api-design

调研方向

从 packages/data-designer-engine/src/data_designer/engine/models/clients/ 开始，阅读 ThrottledModelClient、clients/retry.py 和 clients/types.py。在选择 hook 设计之前，比较现有的 wrapper 和 transport 组合模式。当消费者能够观察到等效的 request 和 response 详细信息（包括 prompt、model、kwargs、response body 和 token usage），并且所选接口具有 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.4k
派生
241
平均合并
1 天 1 小时
30 天内合并 PR
86

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

NVIDIA-NeMo/DataDesigner 的其他 Issue

查看 NVIDIA-NeMo/DataDesigner 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。