hengyuss opened a new issue, #7871:
URL: https://github.com/apache/shenyu/issues/7871
Parent issue: #7351
Related to: #7382
## Background
The current AI Proxy capability model treats protocols accepted from clients
as if they were natively supported by the selected Provider.
For example, an OpenAI Responses request can be accepted by a Chat-compatible
Provider because it is converted to OpenAI Chat, but `AiProviderCapabilities`
does not distinguish native support from support provided through conversion.
Response conversion is also attached to `AiUpstreamRequest`, which mixes the
raw HTTP request model with request-scoped response behavior.
## Goal
Introduce explicit client-protocol to target-protocol routing and a
request-scoped bidirectional protocol conversion contract.
A Provider declares only the protocols it natively supports. `AiProxyEngine`
selects a native target protocol directly when possible, otherwise it
resolves
a registered converter.
Providers that expose OpenAI Responses natively should route Responses
requests
directly to `/v1/responses`. Chat-only Providers should continue using a
Responses-to-Chat converter.
## Scope
* distinguish `clientProtocol` from `targetProtocol` in prepared exchanges;
* define an `AiProtocolConverter` contract and explicit converter registry;
* bind request conversion and response conversion through a request-scoped
conversion result or session;
* move response conversion behavior out of `AiUpstreamRequest`;
* distinguish Provider-native protocols from client protocols supported
through
conversion;
* resolve routes using native passthrough first and conversion second;
* reject unsupported or ambiguous protocol routes before opening an upstream
connection;
* recreate protocol conversion state when switching to a fallback Provider;
* support per-native-protocol Provider endpoint and capability declarations;
* configure the OpenAI Provider with:
* `openai-chat` -> `/v1/chat/completions`;
* `openai-responses` -> `/v1/responses`;
* bypass Chat conversion when OpenAI Responses is selected as a native
target;
* keep generic OpenAI-compatible and DeepSeek profiles Chat-only unless they
explicitly declare native Responses support;
* preserve existing Responses-to-Chat behavior for Chat-only Providers;
* keep protocol conversion independent of HTTP Transport.
## Boundaries
This task does not:
* add new retry or fallback policy;
* harden WebClient or Reactor Netty Transport;
* introduce additional AI Providers;
* add Anthropic, Gemini, or Bedrock protocol conversion;
* require a complete protocol-neutral stream event model if the existing
reactive conversion can be safely wrapped.
## Acceptance criteria
* [ ] `AiUpstreamRequest` contains only upstream HTTP request data.
* [ ] A prepared exchange explicitly identifies client and target protocols.
* [ ] Providers declare native protocols rather than all convertible client
protocols.
* [ ] A native protocol route does not invoke a converter.
* [ ] A non-native protocol route uses a registered request/response
converter.
* [ ] Request and response conversion share request-scoped context.
* [ ] Converter selection is deterministic and duplicate registrations are
rejected.
* [ ] Retry does not leak mutable streaming state between attempts.
* [ ] Fallback resolves a new target protocol and conversion context.
* [ ] Unsupported combinations fail before Transport execution.
* [ ] OpenAI Responses requests sent to the OpenAI Provider use
`/v1/responses`
without Chat conversion.
* [ ] Responses requests sent to a Chat-only Provider use the
Responses-to-Chat converter.
* [ ] Native and converted, streaming and non-streaming paths are covered by
focused tests.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
