Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix fix: replace bare raise Exception with descriptive ValueError in AdapterCompletionStreamWrapper [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25511•Fetched 2026-04-11 06:13:38
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
mohi-devhubmohi-devhub
Participants
mohi-devhubmohi-devhub
Timeline (top)
cross-referenced ×1

The AdapterCompletionStreamWrapper class in litellm/types/utils.py uses bare raise Exception statements which make debugging difficult as they provide no context about what went wrong.

Error Message

The AdapterCompletionStreamWrapper class in litellm/types/utils.py uses bare raise Exception statements which make debugging difficult as they provide no context about what went wrong.

  • Lines 2384, 2396: raise Exception with no message - impossible to debug
  • Replace bare raise Exception with ValueError containing descriptive message
  • Re-raise ValueError explicitly to avoid catching it in the generic Exception handler

Root Cause

The AdapterCompletionStreamWrapper class in litellm/types/utils.py uses bare raise Exception statements which make debugging difficult as they provide no context about what went wrong.

Fix Action

Solution

  • Replace bare raise Exception with ValueError containing descriptive message
  • Replace print() with proper logging using logging.getLogger(__name__).warning()
  • Re-raise ValueError explicitly to avoid catching it in the generic Exception handler

PR fix notes

PR #25512: fix: replace bare raise Exception with descriptive ValueError in streaming wrapper

Description (problem / solution / changelog)

Summary

  • Replace bare raise Exception statements with descriptive ValueError in the AdapterCompletionStreamWrapper class to improve debugging. Also replace print() with proper logging.

Pre-Submission checklist

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem

Type

🐛 Bug Fix

Changes

The AdapterCompletionStreamWrapper class in litellm/types/utils.py used bare raise Exception statements which made debugging impossible since they provided no context about what went wrong. Three fixes in litellm/types/utils.py:

  1. __next__ method — Replace bare raise Exception with ValueError containing descriptive message explaining that a None chunk was received in the stream (usually indicates an issue with adapter response transformation).
  2. __anext__ method — Same fix for the async path.
  3. Both methods — Replace print() statement with proper logging using logging.getLogger(__name__).warning(), and explicitly re-raise ValueError to avoid catching it in the generic Exception handler. Tests: Added test_adapter_completion_stream_wrapper in tests/test_litellm/types/test_types_utils.py covering:
  • Normal chunk iteration works correctly
  • None chunk raises ValueError with descriptive message
  • "None" string raises ValueError
  • Empty iterator raises StopIteration

Relevant issues

Fixes #25511

Changed files

  • litellm/types/utils.py (modified, +14/-3)
  • tests/test_litellm/types/test_types_utils.py (modified, +73/-34)
RAW_BUFFERClick to expand / collapse

Description

The AdapterCompletionStreamWrapper class in litellm/types/utils.py uses bare raise Exception statements which make debugging difficult as they provide no context about what went wrong.

Problem

  • Lines 2384, 2396: raise Exception with no message - impossible to debug
  • Line 2390: print() statement used instead of proper logging

Solution

  • Replace bare raise Exception with ValueError containing descriptive message
  • Replace print() with proper logging using logging.getLogger(__name__).warning()
  • Re-raise ValueError explicitly to avoid catching it in the generic Exception handler

Files affected

  • litellm/types/utils.py - Fixed the __next__ and __anext__ methods in AdapterCompletionStreamWrapper class

Testing

  • Added test test_adapter_completion_stream_wrapper in tests/test_litellm/types/test_types_utils.py
  • Test verifies normal chunk iteration, ValueError on None chunks, and proper StopIteration handling

extent analysis

TL;DR

Replace bare raise Exception statements with descriptive ValueError messages and use proper logging instead of print() to improve debugging.

Guidance

  • Identify and replace all bare raise Exception statements in the AdapterCompletionStreamWrapper class with ValueError containing descriptive messages.
  • Replace the print() statement on line 2390 with logging.getLogger(__name__).warning() for proper logging.
  • Verify that the changes do not introduce any new issues by running the added test test_adapter_completion_stream_wrapper.

Example

# Before
raise Exception

# After
raise ValueError("Descriptive error message")

# Before
print("Warning message")

# After
import logging
logging.getLogger(__name__).warning("Warning message")

Notes

The provided solution focuses on improving debugging by adding context to exceptions and using proper logging. However, the root cause of the exceptions is not addressed and may still require additional investigation.

Recommendation

Apply the workaround by replacing bare raise Exception statements with descriptive ValueError messages and using proper logging, as this will improve debugging and provide more context when issues arise.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#database connection#vector store#embedding generation#cache error#pipeline error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING