fix(ci): let the E2E proxy accept the mock testing params its suite sends

[yuneng-berri]

TLDR

Problem this solves:

• build_and_test is red on tests/test_fallbacks.py
• Mock testing params are now gated; the CI proxy config never opted in
• Every fallback, retry and timeout drill 400s

How it solves it:

• Opt proxy_server_config.yaml into the gate's config flag
• Add a unit test tying the E2E suite to the config it runs against

Relevant issues

Follow-up to #35423, which gated the six mock testing request params behind general_settings.dangerously_allow_mock_testing_request_params. The gate itself is correct; this only wires up the CI proxy that the E2E fallback suite drives.

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 (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Screenshots / Proof of Fix

The build_and_test job runs the top-level tests/test_*.py suite against a proxy container mounted with proxy_server_config.yaml, alongside tests/_fake_openai_endpoint_server.py on port 8190. I reproduced that shape locally: the fake OpenAI endpoint on 8191, an isolated Postgres, and a proxy on 4011 carrying the model entries the five affected tests use. Two honest caveats about the local stand-in. My .env has no OPENAI_API_KEY, so gpt-3.5-turbo and gpt-instruct are backed by anthropic/claude-sonnet-5 and anthropic/claude-haiku-4-5 instead; the successful fallback below is a real, paid Anthropic call. And fake-openai-endpoint-4 / fake-openai-endpoint-5 point at the same canned endpoint CI uses, because the timeout and retry drills assert on synthetic failures that by design never reach a provider.

Each block below names the test whose assertion it stands in for.

Before, at b1fd20f4cd (branch point, config unmodified):

### test_chat_completion_client_fallbacks[True] -- key CAN reach the fallback model
{"error":{"message":"Mock testing request params are disabled on this proxy: mock_testing_fallbacks. An admin can enable them by setting `general_settings.dangerously_allow_mock_testing_request_params: true` in config.yaml. This setting cannot be changed from the Admin UI or the API.","type":"None",
HTTP 400

### test_chat_completion_client_fallbacks[False] -- key CANNOT reach the fallback model
{"error":{"message":"key not allowed to access model. This key can only access models=['gpt-3.5-turbo']. Tried to access gpt-instruct","type":"key_model_access_denied","param":"model","code":"403"}}
HTTP 403

### test_chat_completion_with_timeout -- expects x-litellm-timeout: 1.0
HTTP/1.1 400 Bad Request

### test_chat_completion_with_timeout_from_request -- expects x-litellm-timeout: 0.001
HTTP/1.1 400 Bad Request

### test_chat_completion_with_retries -- expects attempted-retries 1, max-retries 50
HTTP/1.1 400 Bad Request

That maps 1:1 onto the two failures reported from CI. test_chat_completion_client_fallbacks[True] raises Request did not return a 200 status code: 400, and test_chat_completion_with_timeout gets no x-litellm-timeout header on the 400 and dies with KeyError: 'x-litellm-timeout'. The [False] parametrization is unaffected either way: the key's model ACL is checked before the mock gate, so it still fails for the reason it is meant to.

After, at 86312da3be:

### test_chat_completion_client_fallbacks[True] -- key CAN reach the fallback model
{"id":"chatcmpl-7480b118-931e-44b2-8c07-c7fcbf6dc189","created":1785621452,"model":"claude-haiku-4-5-20251001","object":"chat.completion","choices":[{"finish_reason":"stop","index":0,"message":{"content":"# Alexander\n\nYou're likely asking about **Alexander the Great** (356-323 BCE), the most famou
HTTP 200

### test_chat_completion_client_fallbacks[False] -- key CANNOT reach the fallback model
{"error":{"message":"key not allowed to access model. This key can only access models=['gpt-3.5-turbo']. Tried to access gpt-instruct","type":"key_model_access_denied","param":"model","code":"403"}}
HTTP 403

### test_chat_completion_with_timeout -- expects x-litellm-timeout: 1.0
HTTP/1.1 408 Request Timeout
x-litellm-timeout: 1.0

### test_chat_completion_with_timeout_from_request -- expects x-litellm-timeout: 0.001
HTTP/1.1 408 Request Timeout
x-litellm-timeout: 0.001

### test_chat_completion_with_retries -- expects attempted-retries 1, max-retries 50
HTTP/1.1 200 OK
x-litellm-attempted-retries: 1
x-litellm-max-retries: 50

The [True] case is served by claude-haiku-4-5, the fallback deployment, which is the point: the primary was made to fail synthetically and the fallback answered for real.

To rerun it yourself, start the canned endpoint and a proxy carrying those five models, then:

curl -s -D - -o /dev/null -X POST http://localhost:4000/chat/completions -H 'Authorization: Bearer sk-1234' -H 'Content-Type: application/json' -d '{"model":"fake-openai-endpoint-5","messages":[{"role":"user","content":"Who was Alexander?"}],"num_retries":0,"mock_timeout":true}'

Type

🚄 Infrastructure

Changes

proxy_server_config.yaml gets general_settings.dangerously_allow_mock_testing_request_params: true. That is the config the build_and_test proxy container runs with, and the suite it serves exists to drive synthetic failures through the router, so the opt-in belongs there.

One consequence worth naming: docker-compose.hardened.yml mounts the same file, so that local stack now accepts mock testing params too. It is a build-and-QA stack rather than a deployment template, and it shares the file precisely because it is the CI config, but a reviewer who would rather keep the word "hardened" absolute can say so and I will split it onto its own config.

The new test in tests/test_litellm/proxy/test_route_llm_request.py scans the top-level tests/test_*.py files that build_and_test globs for any of GATED_MOCK_PARAM_NAMES, then asserts the config those tests run against has opted in. It fails with the offending param names listed, and it is red on the parent commit and green on this one. The value is the turnaround: this gap currently surfaces only after a Docker image build and a full E2E job, and now it surfaces in the unit tier.

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

[greptile-apps]

Greptile Summary

The PR enables gated mock-testing request parameters in the proxy configuration used by the E2E fallback suite and adds a unit-level regression check coupling that suite to its configuration.

• Opts proxy_server_config.yaml into synthetic fallback, retry, delay, and timeout parameters.
• Adds a test that detects gated parameter usage in the top-level E2E suite and requires the proxy configuration flag.

Confidence Score: 5/5

The PR appears safe to merge, with the configuration change scoped to confirmed testing stacks and covered by a focused regression check.

The changed CI proxy configuration now permits the synthetic parameters exercised by the fallback suite, while the added test ensures the required opt-in is not removed while those parameters remain in use.

Important Files Changed

Filename	Overview
proxy_server_config.yaml	Enables test-only mock request parameters for the CI and hardened QA proxy stacks that consume this configuration.
tests/test_litellm/proxy/test_route_llm_request.py	Adds a regression test ensuring the top-level E2E suite's gated mock parameters remain compatible with its mounted proxy configuration.

_{Reviews (1): Last reviewed commit: "fix(ci): let the E2E proxy accept the mo..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!