Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Add request/response logging hook to native model client

Abierto
  • ¿Algo no está bien?
#503 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@chethanuk ya está trabajando en esto.

Desde el 6/10/2026.

  • #983 de @chethanuk — cerrado sin fusionar

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
ai, api, backend-api-design

Línea de trabajo

Comienza en packages/data-designer-engine/src/data_designer/engine/models/clients/ y lee ThrottledModelClient, clients/retry.py y clients/types.py. Compara los patrones existentes de composición de wrappers y transportes antes de elegir un diseño de hook. El issue estará terminado cuando los consumidores puedan observar detalles equivalentes de las requests y responses, incluidos los prompts, el modelo, kwargs, el cuerpo de la response y el uso de tokens, con cobertura para la interfaz seleccionada.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Python
Estrellas
2.3k
Forks
227
Merge medio
22 h 13 min
PR fusionados (30 d)
63

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NVIDIA-NeMo/DataDesigner

Todos los issues de NVIDIA-NeMo/DataDesigner

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.