dev404ai commented on issue #13340: URL: https://github.com/apache/apisix/issues/13340#issuecomment-5253066666
While investigating this issue, I ran a small deterministic probe on Apple arm64 against unchanged APISIX source at `master` 39b9e43. It exposed a concrete fixture-fidelity gap on the request side — the same side the quoted concern is about. The existing `t/plugin/ai-proxy-fixture.t` baseline passes all 50 assertions. In a separate local probe against the unchanged fake server, `GET /v1/messages` with only `X-AI-Fixture: anthropic/messages-basic.json` returned 200 and the recorded response despite having no Anthropic auth headers or request body. As a control, the existing Bedrock Converse handler rejected the same invalid method with 400. This shows that the fake server can accept an invalid provider request shape and still return a plausible fixture response. Response-focused fixture tests could therefore miss adapter regressions in the method or required fields. To be clear about scope: this is a test-fidelity observation, not a security report. `t/` and `t/lib/` are out of the project's threat model per §4.2 and §4.3 point 10 of `docs/en/latest/security-threat-model.md`. This evidence does not by itself justify a separate LLM fake-server container. The current server already enforces a detailed request contract for Bedrock, so provider-specific validation in the existing server appears to be the smallest change that closes the demonstrated gap. A separate container may still be useful if the intended scope includes behavior that the current server cannot represent reliably, such as stateful interactions, provider SDK behavior, transport-level differences, or more realistic streaming. Is there a container-specific requirement beyond request-contract validation that should define the boundary of #13340? -- 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]
