Fix Bedrock passthrough call ID headers

[ishaan-berri]

Summary

Non-streaming ALLM passthrough responses were rebuilding a FastAPI response from the upstream provider response after common request processing had already attached LiteLLM metadata headers to the injected response object. The fix merges those accumulated LiteLLM headers into the final passthrough response so Bedrock Invoke responses include the call ID while preserving provider headers.

Repro

Call a non-streaming Bedrock passthrough route such as /bedrock/model/<bedrock-model-id>/invoke. Before the fix, provider headers like x-amzn-requestid were returned, but x-litellm-call-id was missing from the client response.

Evidence

Goal: the final passthrough response should include the upstream Bedrock-style headers and LiteLLM metadata headers, including x-litellm-call-id.

Focused proof run after the fix:

status: 200
provider header x-amzn-requestid: bedrock-request-id
litellm header x-litellm-call-id: test-call-id
litellm header x-litellm-version: test-version
.                                                                        [100%]
1 passed in 1.80s

Regression observed before the fix:

FAILED tests/test_litellm/proxy/test_common_request_processing.py::TestProxyBaseLLMRequestProcessing::test_base_passthrough_process_llm_request_preserves_litellm_headers_for_non_streaming_response
KeyError: 'x-litellm-call-id'

Tests

• Added tests/test_litellm/proxy/test_common_request_processing.py::TestProxyBaseLLMRequestProcessing::test_base_passthrough_process_llm_request_preserves_litellm_headers_for_non_streaming_response.
• Confirmed the new regression test failed before the fix with KeyError: x-litellm-call-id.
• uv run pytest tests/test_litellm/proxy/test_common_request_processing.py -q -> 87 passed.
• CI-scope lint/type/import checks from .github/workflows/test-linting.yml passed locally: lock check, frozen sync, Black check, Ruff, MyPy, circular import check, and import safety.

CI

• GitHub Actions checks on the PR head: green, including LiteLLM Linting, unit-test workflows, UI build, code quality, Semgrep, and MCP tests.
• CircleCI: most contexts green. realtime_translation_testing is failing on the PR and also failing on litellm_internal_staging, so it appears pre-existing. litellm_utils_testing is failing on the PR while the latest base-branch status is green; CircleCI job logs were not accessible from this environment, and the code change is limited to proxy passthrough response headers plus a proxy unit test.

Review

• Greptile check completed successfully: 2 files reviewed, 0 comments added. No review score was exposed in the available check output.

Relevant issues

Internal bug report.

Linear ticket

N/A

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

Screenshots / Proof of Fix

See Evidence above.

Type

🐛 Bug Fix
✅ Test

Changes

• Preserve LiteLLM custom headers when finalizing non-streaming passthrough responses.
• Add a regression test covering Bedrock-like provider headers plus LiteLLM call metadata.

  

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

This PR fixes a header propagation bug where non-streaming Bedrock passthrough responses were losing LiteLLM metadata headers (e.g., x-litellm-call-id) because the Response was being rebuilt without the headers that had been accumulated on the injected fastapi_response object during common request processing.

• Core fix: In base_passthrough_process_llm_request, custom_headers=None is replaced with custom_headers=dict(fastapi_response.headers), so headers set on fastapi_response during base_process_llm_request are merged into the final client response via the existing get_response_headers utility.
• Test: A new mock-based regression test verifies that both provider headers (e.g., x-amzn-requestid) and LiteLLM metadata headers (x-litellm-call-id, x-litellm-version) are present in the final response for the non-streaming path.

Confidence Score: 5/5

Safe to merge — the change is minimal and isolated to the non-streaming passthrough rebuild path, with a targeted regression test that directly validates the fix.

The one-line change correctly threads the accumulated fastapi_response headers into get_response_headers, which already has safe merge semantics (provider headers first, then custom headers on top). The streaming path is unaffected. The test is mock-only, covers the exact failure mode described in the PR, and makes no real network calls.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/proxy/common_request_processing.py	Single-line fix: passes accumulated fastapi_response headers as custom_headers when rebuilding the non-streaming passthrough Response, ensuring x-litellm-call-id and other LiteLLM metadata headers are included in the client response.
tests/test_litellm/proxy/test_common_request_processing.py	Adds a regression test using mocks that simulates the Bedrock non-streaming passthrough path, verifying both provider headers and LiteLLM metadata headers survive in the final response. No real network calls made.

_{Reviews (1): Last reviewed commit: "Preserve LiteLLM headers for passthrough..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!