nic-6443 opened a new pull request, #13851: URL: https://github.com/apache/apisix/pull/13851
`ai-proxy-multi` lets two instances carry the same `name`, but the runtime treats `instance.name` as the instance identity. It keys the balancer nodes (`up_nodes[priority][name]`), the health checker (`checkers[name]`) and the health status (`status[name]`) — none of which include the priority — so instances sharing a name collapse into one logical node with one checker. The result is that one instance's health decides the other's fate: with several instances pointing at the same endpoint but different API keys (a common multi-key setup), a single bad key marks the shared node unhealthy and takes the working keys down with it, while requests that do go out use the first matching instance's auth. Lookups by name return the first match, so which config is used and which one is health-checked can disagree. The name is also how `ai-rate-limiting` and `semantic_opts.fallback` reference an instance, so a duplicate is ambiguous across the whole config surface, not just in the balancer. This rejects duplicates in `check_schema`: ``` duplicate instance name 'my-instance' at instances[1] and instances[3] ``` Note this makes an existing config invalid: a route whose `ai-proxy-multi` instances share a name is rejected on the next write and dropped on reload. That configuration is already broken at runtime in the way described above, and giving distinct names is the fix users apply anyway, but it is a behaviour change on upgrade. Tests cover the rejection and that distinct names still pass. -- 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]
