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

#27388 [Bug] arize_phoenix callback spans not exported from proxy chat completions in v1.83.10

  • State: open
  • Author: @sdelbustobusuu

## Bug description

When LiteLLM proxy v1.83.10 is configured with `arize_phoenix` as a `success_callback`, the callback IS invoked on each successful chat completion (verified via DEBUG logs), but the spans created inside `ArizePhoenixLogger._handle_success` never reach the Phoenix OTLP endpoint. The `BatchSpanProcessor` worker on the dedicated TracerProvider does not flush these spans even after extended idle time and even with aggressive BSP env-var tuning.

## Environment

- LiteLLM image: `ghcr.io/berriai/litellm-database:v1.83.10-stable` - Deployment: Helm chart in Kubernetes (EKS), proxy mode (FastAPI/uvicorn, async) - Phoenix: self-hosted `arize-phoenix` 14.2.0 (helm chart 6.0.7), auth enabled, OTLP HTTP endpoint at `http://arize-phoenix-svc...:6006/v1/traces` - Python 3.13

## Configuration

```yaml litellm_settings: success_callback: - arize_phoenix ```

Env vars set: - `PHOENIX_COLLECTOR_HTTP_ENDPOINT=http://arize-phoenix-svc...:6006/v1/traces` - `PHOENIX_API_KEY=<system api key>` (Phoenix has `enableAuth: true`)

## What works

- Phoenix endpoint reachable and accepts POSTs to `/v1/traces` (200 OK) - API key validates correctly - `ArizePhoenixLogger` initializes: …

GitHub resolver

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

Refresh page
vote history (3 events)
#0 of 0 · 31d19h17m58s ago — entered · #import:https:::github.com:berriai:litellm post #1882
The right issue is harder because it requires a cross-version integration migration, dependency-policy changes, API and lifecycle compatibility work, and broad regression coverage. The left issue is narrower in scope, primarily involving tracing-provider lifecycle and asynchronous export behavior within one callback path.
The right issue is harder because it involves tracing lifecycle, asynchronous batching, provider-specific integration, and deployment/runtime compatibility, requiring investigation across multiple components and likely end-to-end validation. The left issue is comparatively localized to parsing and pagination handling in a repository automation script.
#0 of 0 · 31d19h7m13s ago — current · #import:https:::github.com:berriai:litellm post #2068
Tracing delivery failure spans provider integration, async worker lifecycle, batching, and deployment-specific behavior, requiring broader investigation and end-to-end validation; the guardrail issue is comparatively localized decision logic with focused tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search