fix(responses): preserve Bedrock Mantle validation errors

[uuzzrm]

TLDR

Problem this solves:

• Bedrock Mantle validation failures reach callers as status 500
• The upstream 400 response is treated like a connection failure

How it solves it:

• Routes Bedrock Mantle through the existing Bedrock status mapping
• Preserves BadRequestError, status 400, and the upstream message

User Flow

Before: a Responses API caller receives the wrong error class for an invalid request

1. They send POST https://bedrock-mantle.us-east-1.api.aws/openai/v1/responses with a Responses request
2. Mantle rejects the request with HTTP 400 and an invalid_request_error body
3. The caller receives APIConnectionError with status 500 and cannot distinguish validation from connectivity

After: the same invalid request is reported as a client error

1. They send POST https://bedrock-mantle.us-east-1.api.aws/openai/v1/responses with the same Responses request
2. Mantle rejects the request with HTTP 400 and an invalid_request_error body
3. The caller receives BadRequestError with status 400 and the upstream validation message

Relevant issues

Addresses the error-classification portion of #36546

Linear ticket

Pre-Submission checklist

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

The before run was captured against commit bea31871fc with a mocked HTTP 400 response. Both sync and async litellm.responses() paths raised APIConnectionError with status 500

The after run was captured against commit f6f6044e09 with the same mocked HTTP 400 response. Both paths raised BadRequestError with status 400 and preserved Invalid 'input'

Targeted regression tests passed:

uv run --no-sync pytest tests/test_litellm/litellm_core_utils/test_exception_mapping_utils.py -q -> 63 passed

uv run --no-sync pytest tests/test_litellm/llms/bedrock_mantle/test_bedrock_mantle_responses_transformation.py -q -> 116 passed

No live Bedrock credentials were available in this environment, so I did not include a live provider run

Type

Bug Fix

Caveats (if any)

Live Bedrock verification still needs to run with provider credentials

This PR covers the 400-to-500 error masking. Input-item normalization remains a separate concern

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

AI assistance: this patch was prepared and tested with AI coding assistance. The implementation, reproduction, and test scope are included for maintainer review

[greptile-apps]

Greptile Summary

The PR maps Bedrock Mantle failures through the existing Bedrock exception mapper so upstream validation responses retain their status and message.

• Adds Bedrock Mantle to the Bedrock exception-dispatch branch.
• Adds regression coverage for mapping a Mantle HTTP 400 response to BadRequestError.

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains.

No blocking failure remains.

Important Files Changed

Filename	Overview
litellm/litellm_core_utils/exception_mapping_utils.py	Extends Bedrock exception mapping to Bedrock Mantle, preserving upstream client-error classification.
tests/test_litellm/litellm_core_utils/test_exception_mapping_utils.py	Adds a focused regression test asserting that a Mantle HTTP 400 preserves its status and validation message.

_{Reviews (2): Last reviewed commit: "fix(responses): preserve Bedrock Mantle ..." | Re-trigger Greptile}

[greptile-apps]

Provider-specific dispatch in core

Adding bedrock_mantle here places provider-specific behavior outside the provider layer, fragmenting its error handling and increasing the maintenance cost when the Mantle adapter evolves.

Rule Used: What: Avoid writing provider-specific code outside... (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing uuzzrm:litellm_bedrock_mantle_400_errors (f6f6044) with litellm_internal_staging (29fe342)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (f99d0a4) during the generation of this report, so 29fe342 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[mayank-affirm]

Thanks for fixing the 400 -> 500 masking. There is one related compatibility gap worth covering in this PR (or a linked follow-up).

Bedrock Mantle can return this validation error for context overflow:

{"error":{"code":"validation_error","message":"prompt tokens (1055489) exceed model maximum (1050000) for openai.gpt-5.6-sol","param":null,"type":"invalid_request_error"}}

This PR should preserve it as HTTP 400, but preserving the upstream message verbatim is not sufficient for Claude Code recovery. Claude Code 2.1.234 recognizes context overflow only when a 400/413 message contains a known phrase such as prompt is too long; the Mantle wording above is not recognized, so reactive compaction does not run.

Could the Bedrock Mantle mapping also detect the structured 400 invalid_request_error / validation_error plus the narrow prompt tokens (...) exceed model maximum (...) pattern, raise ContextWindowExceededError, and normalize the client-facing message to something like:

prompt is too long: 1055489 tokens > 1050000 maximum

A focused regression test should assert both status_code == 400 and the canonical phrase, while ensuring unrelated Mantle validation errors remain ordinary BadRequestErrors. This would make the fix useful to Claude Code clients as well as preserve the correct HTTP semantics.