litellm - ✅(Solved) Fix refactor(predibase): migrate transform_request and transform_response from handler.py to transformation.py [1 pull requests, 1 comments, 2 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#25205Fetched 2026-04-08 02:53:07
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
Participants
Timeline (top)
commented ×1cross-referenced ×1

litellm/llms/predibase/chat/transformation.py has a PredibaseConfig class that inherits from BaseConfig, but both transform_request() and transform_response() currently raise NotImplementedError with an explicit TODO:

# transformation.py:138
raise NotImplementedError(
    "Predibase transformation currently done in handler.py. Need to migrate to this file."
)

# transformation.py:150
raise NotImplementedError(
    "Predibase transformation currently done in handler.py. Need to migrate to this file."
)

The actual logic lives in handler.py inside PredibaseChatCompletion.process_response() (response parsing) and PredibaseChatCompletion.completion() (request building). This is inconsistent with every other provider in the codebase that uses the BaseConfig pattern.

Error Message

  • JSON parsing and error handling

Root Cause

  • Inconsistency makes it harder for contributors to understand the Predibase integration
  • BaseConfig subclasses are the standard pattern — providers like OpenAI, Anthropic, Gemini all follow it
  • The NotImplementedError means any future work trying to use PredibaseConfig via the standard path will fail silently

PR fix notes

PR #25249: refactor(predibase): migrate transform_request and transform_response…

Description (problem / solution / changelog)

… to transformation.py

Relevant issues

<!-- e.g. "Fixes #000" -->

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • 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
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

CI (LiteLLM team)

CI status guideline:

  • 50-55 passing tests: main is stable with minor issues.
  • 45-49 passing tests: acceptable but needs attention
  • <= 40 passing tests: unstable; be careful with your merges and assess the risk.
  • Branch creation CI run
    Link:

  • CI run for the last commit
    Link:

  • Merge / cherry-pick CI run
    Links:

Type

<!-- Select the type of Pull Request --> <!-- Keep only the necessary ones -->

🆕 New Feature 🐛 Bug Fix 🧹 Refactoring 📖 Documentation 🚄 Infrastructure ✅ Test

Changes

  • Migrated Predibase request building logic from litellm/llms/predibase/chat/handler.py into litellm/llms/predibase/chat/transformation.py by implementing PredibaseConfig.transform_request().
  • Migrated Predibase response parsing logic from handler.py into PredibaseConfig.transform_response() (including generated text parsing, finish reason/logprob extraction, best-of handling, usage calculation, and x-* header forwarding).
  • Added PredibaseConfig.get_complete_url() to centralize Predibase URL construction and /generate vs /generate_stream selection.
  • Moved output_parser() logic to transformation.py and removed duplicate logic from the handler.
  • Slimmed PredibaseChatCompletion in handler.py to delegate transformation concerns to PredibaseConfig while preserving existing sync/async + streaming execution paths.
  • Added focused unit tests in tests/test_litellm/llms/test_predibase_transformation.py for:
    • request transformation
    • custom prompt branch
    • stream/non-stream URL resolution
    • response transformation success path (including best-of + headers)
    • response error handling (invalid json, error field)

Relevant issues

Fixes #25205

Pre-Submission checklis

  • I have Added testing in the tests/test_litellm/ directory
  • My PR passes all unit tests on make test-unit
    (local environment blocked by optional enterprise dependency import in full suite; targeted tests for this change pass)
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Type

🧹 Refactoring
✅ Test

Changed files

  • litellm/llms/predibase/chat/handler.py (modified, +43/-228)
  • litellm/llms/predibase/chat/transformation.py (modified, +205/-7)
  • tests/test_litellm/llms/test_predibase_transformation.py (added, +569/-0)

Code Example

# transformation.py:138
raise NotImplementedError(
    "Predibase transformation currently done in handler.py. Need to migrate to this file."
)

# transformation.py:150
raise NotImplementedError(
    "Predibase transformation currently done in handler.py. Need to migrate to this file."
)
RAW_BUFFERClick to expand / collapse

Summary

litellm/llms/predibase/chat/transformation.py has a PredibaseConfig class that inherits from BaseConfig, but both transform_request() and transform_response() currently raise NotImplementedError with an explicit TODO:

# transformation.py:138
raise NotImplementedError(
    "Predibase transformation currently done in handler.py. Need to migrate to this file."
)

# transformation.py:150
raise NotImplementedError(
    "Predibase transformation currently done in handler.py. Need to migrate to this file."
)

The actual logic lives in handler.py inside PredibaseChatCompletion.process_response() (response parsing) and PredibaseChatCompletion.completion() (request building). This is inconsistent with every other provider in the codebase that uses the BaseConfig pattern.

What needs to be done

  1. Implement transform_request() in transformation.py — move the request-building logic from handler.py:completion():

    • URL construction (/generate vs /generate_stream)
    • Prompt formatting via prompt_factory()
    • Config loading and data = {"inputs": prompt, "parameters": optional_params} assembly
  2. Implement transform_response() in transformation.py — move the response-parsing logic from handler.py:process_response():

    • JSON parsing and error handling
    • output_parser() for ChatML token stripping
    • logprobs + finish reason extraction from details
    • best_of multi-choice handling
    • Usage token counting
    • Response header forwarding (x-* headers → _hidden_params)
  3. Slim down handler.py to delegate to transformation.py methods instead of owning the logic directly.

  4. Add unit tests in tests/litellm/ covering transform_request and transform_response for both streaming and non-streaming cases.

Why this matters

  • Inconsistency makes it harder for contributors to understand the Predibase integration
  • BaseConfig subclasses are the standard pattern — providers like OpenAI, Anthropic, Gemini all follow it
  • The NotImplementedError means any future work trying to use PredibaseConfig via the standard path will fail silently

Files affected

  • litellm/llms/predibase/chat/transformation.py — implement the two methods
  • litellm/llms/predibase/chat/handler.py — delegate to transformation, remove duplicated logic
  • tests/litellm/llms/test_predibase_transformation.py — new test file

Notes

validate_environment() and map_openai_params() are already correctly implemented in transformation.py — only transform_request and transform_response need work. The output_parser() helper in handler.py can move to transformation.py or common_utils.py.

extent analysis

TL;DR

Implement transform_request() and transform_response() in transformation.py by migrating logic from handler.py to align with the BaseConfig pattern.

Guidance

  • Move the request-building logic from handler.py:completion() to transformation.py:transform_request(), including URL construction, prompt formatting, and config loading.
  • Move the response-parsing logic from handler.py:process_response() to transformation.py:transform_response(), including JSON parsing, error handling, and output parsing.
  • Update handler.py to delegate to the new methods in transformation.py instead of owning the logic directly.
  • Add unit tests in tests/litellm/ to cover both streaming and non-streaming cases for transform_request and transform_response.

Example

# transformation.py
class PredibaseConfig(BaseConfig):
    def transform_request(self, prompt, optional_params):
        # Move logic from handler.py:completion() here
        url = "/generate" if not self.streaming else "/generate_stream"
        data = {"inputs": prompt_factory(prompt), "parameters": optional_params}
        return url, data

    def transform_response(self, response):
        # Move logic from handler.py:process_response() here
        try:
            response_json = response.json()
            output = output_parser(response_json)
            # Extract logprobs, finish reason, and usage tokens
            return output
        except Exception as e:
            # Handle error
            pass

Notes

The output_parser() helper can be moved to either transformation.py or common_utils.py. The existing validate_environment() and map_openai_params() methods in transformation.py do not need to be modified.

Recommendation

Apply workaround by implementing the missing methods in transformation.py and updating handler.py to delegate to these new methods, as this will bring the Predibase integration in line with the standard BaseConfig pattern used by other providers.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING