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

#27138 [Bug]: Bedrock Converse injects tools into payload when caller sends none, drop_params=True doesn't help

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

## Description

When calling a Bedrock model that does **not** support tool use (e.g. `meta.llama3-2-3b-instruct-v1:0`) via LiteLLM's Bedrock Converse handler, the request fails with:

``` BedrockException - {"message":"This model doesn't support tool use."} ```

The caller is **not sending any `tools` field**. Setting `drop_params=True` does **not** fix it.

## Steps to Reproduce

```python import litellm

response = await litellm.acompletion( model="bedrock/meta.llama3-2-3b-instruct-v1:0", messages=[{"role": "user", "content": "Hello"}], drop_params=True, # No `tools` field ) ```

## Expected Behavior

Request succeeds. No tool definitions are sent to Bedrock when the caller did not provide any.

## Actual Behavior

``` httpx.HTTPStatusError: Client error '400 Bad Request' for url '.../converse'

litellm.exceptions.BadRequestError: BedrockException - {"message":"This model doesn't support tool use."} ```

Full traceback points to `converse_handler.py` → `async_completion`.

## Root Cause (suspected)

`converse_handler.py` → `async_completion` injects tool definitions into the Converse payload unconditionally (or based on some upstream state). `drop_params=True` do…

GitHub resolver

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

Refresh page
vote history (7 events)
#0 of 0 · 31d19h21m17s ago — entered · #import:https:::github.com:berriai:litellm post #1726
Bedrock handling requires tracing request construction and conditional tool state across provider-specific paths, with compatibility and regression testing; the Ollama change is a localized precedence fix with limited validation scope.
The left issue requires broader response-schema handling, compatibility decisions, and coverage for multi-turn/tool-result conversion paths; the right issue appears localized to request construction in one provider handler with a comparatively narrow regression test.
Guardrail configuration/database synchronization spans startup initialization, persistence, and precedence semantics, making it broader and riskier than a localized provider payload-condition fix with focused regression coverage.
31827 is harder because it requires a new cross-cutting configuration and precedence mechanism spanning proxy validation, request parameter merging, provider translation, security semantics, and broad compatibility testing. 27138 is comparatively localized to Bedrock request construction with focused regression coverage.
Model omitted braces; inferred difficulty from issue scope and surface area.
The left issue spans proxy routing, credential resolution, and managed-resource integration behavior, creating broader regression risk and requiring end-to-end coverage. The right is comparatively localized to provider request construction with focused adapter tests.
#0 of 0 · 31d18h39s ago — current · #import:https:::github.com:berriai:litellm post #3064
29657 likely requires cross-cutting policy clarification and implementation across user/team identity resolution, key generation, rate-limit enforcement, persistence, API behavior, UI support, and regression coverage. 27138 appears more localized to request translation and conditional payload construction with targeted provider tests, so it carries less scope and integration risk.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search