[Bug]: LLM Proxy Creation Fault 404 when given Non Existing LLM Provider

Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI)

Description

Creating an LLM proxy that references a non-existent provider is correctly rejected, but the rejection is reported with the wrong status code and a message that names the wrong object.

Expectation: 400 Bad Request
Actual: 404 Not Found

Identified Inconsistencies

1. The status code is undeclared. management-openapi.yaml declares exactly 201, 400, 409, 500 for POST /llm-proxies — no 404. The declared 400 is documented as "Invalid configuration (validation failed)", which is precisely what a dangling provider reference is. A generated client may not model 404 on this operation at all.
2. The message names the wrong resource. The entity that could not be found is the provider. The message reports the proxy — which is the resource being created, so its absence is trivially true and tells the user nothing. The failing provider id appears nowhere in the response, so there is no way to tell which reference was bad.

Related: the same root cause affects PUT /llm-proxies/{id}, where a well-formed update pointing at a missing provider also answers 404 naming the proxy. There, 404 is declared, so it is not a spec violation — but the response is still indistinguishable from a genuine proxy-not-found. Worth fixing together.

Steps to Reproduce

Case A — dangling primary provider

1. Start a gateway with the management API reachable. No control plane or special configuration is needed; a default single-gateway topology is sufficient.
2. Choose a provider id that does not exist — any string that was never created.
3. Send a POST to /api/management/v1/llm-proxies with a well-formed LlmProxy body whose spec.provider.id is that non-existent id. Set an explicit spec.context so the request is valid in every other respect.
4. Observe the response. It is 404 with {"message":"LLM proxy configuration not found","status":"error"}, where 400 is expected.
5. Confirm the proxy was genuinely not created by sending a GET to /api/management/v1/llm-proxies/{name} — it correctly returns 404. This shows the reject itself is right and only the create response is wrong.

Case B — valid primary, dangling entry in additionalProviders

6. Create an LLM provider normally and confirm it returns 201.
7. Send a POST to /api/management/v1/llm-proxies with a proxy whose spec.provider.id is the provider created in step 6 (valid), and whose spec.additionalProviders contains one entry with an id that does not exist — aliased, and referenced as a model target from a model-round-robin policy.
8. Observe the identical 404 and identical message, even though the primary provider resolved successfully a moment earlier. This confirms the defect is not sensitive to lookup order and is not avoidable by having a valid primary.

Severity Level of the Issue

Severity/Major (Important functionality is broken. Should be prioritized. Doesn't need immediate attention)

Environment Details (with versions)

No response

Start with management-openapi.yaml and the POST /api/management/v1/llm-proxies and PUT /api/management/v1/llm-proxies/{id} entry points. Trace how missing provider references are validated and mapped to responses; done means creation reports 400 with the provider id, while updates distinguish a missing provider from a missing proxy.