6 views
-/https://github.com/berriai/litellm/issues/29266
GitHub · issue

#29266 [Bug]: /health/test_connection ignores model_info — health_check_supports_max_tokens: false never respected

  • State: open
  • Author: @sebinpj
  • Labels: llm translation

## Description

In `test_model_connection` (`litellm/proxy/health_endpoints/_health_endpoints.py`), `_update_litellm_params_for_health_check` is called with a hardcoded `model_info={}` instead of passing the actual `model_info` from the request. This means `health_check_supports_max_tokens: false` set in `model_info` is silently ignored when using the UI "Test Connection" button — `max_tokens: 5` is always injected regardless of the setting.

## Steps to Reproduce

1. Add a model to `config.yaml` with `model_info: { health_check_supports_max_tokens: false }`: ```yaml model_list: - model_name: my-model litellm_params: model: openai/my-deployment api_base: https://... api_key: ... custom_llm_provider: openai model_info: health_check_supports_max_tokens: false ``` 2. Start LiteLLM proxy and go to the UI → Models tab 3. Click **"Test Connection"** for that model 4. Observe the outgoing request to the backend — it includes `max_tokens: 5`

## Expected Behavior

`max_tokens` should **not** be sent when `health_check_supports_max_tokens: false` is configured, matching the behavior of the background `/health` endpoint…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (5 events)
#0 of 0 · 31d19h13m59s ago — entered · #import:https:::github.com:berriai:litellm post #1652
The right issue is harder because it involves defensive handling across an observability callback, compatibility with multiple response shapes, validation of attribute types, and regression testing across integration paths. The left issue appears localized to parameter propagation at a single health-check call site.
The left task spans provider-specific routing, model translation, endpoint/authentication behavior, and compatibility testing across AWS integrations. The right task is a narrowly scoped parameter-propagation fix with focused regression coverage, so the left carries substantially greater integration risk.
Cross-component deployment configuration, secret precedence, template behavior, and regression testing create substantially more integration risk; the other is a localized parameter-propagation fix with narrower test scope.
The left task requires broader configuration semantics, metric discovery, label filtering, backward compatibility, and comprehensive validation. The right task is a localized data-flow correction with focused regression coverage.
#0 of 0 · 31d19h10m20s ago — current · #import:https:::github.com:berriai:litellm post #1714
The left task has broader cross-provider behavior, proxy integration, edge cases, and compatibility testing, while the right task appears localized to parameter propagation with focused regression coverage.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search