fix(ai-proxy-multi): reject instances that share a name - #13851
Merged
nic-6443 merged 1 commit intoAug 20, 2026
Conversation
instance.name is the only identifier the runtime has for an instance: it keys the balancer nodes, the health checker and the health status, none of which include the priority. Two instances sharing a name therefore collapse into a single logical node with a single checker, so one instance's health decides the other's fate while requests keep using the first instance's auth -- a config with one bad API key can take the healthy instances down with it. Reject duplicate names in check_schema instead of routing on that ambiguity. The name is also how other plugins (ai-rate-limiting) and semantic_opts.fallback reference an instance, so a duplicate is ambiguous throughout the config surface, not only in the balancer.
dosubot
Bot
added
the
size:L
AlinsRan
approved these changes
Aug 20, 2026
shreemaan-abhishek
approved these changes
Aug 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ai-proxy-multilets two instances carry the samename, but the runtime treatsinstance.nameas 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-limitingandsemantic_opts.fallbackreference an instance, so a duplicate is ambiguous across the whole config surface, not just in the balancer. This rejects duplicates incheck_schema:Note this makes an existing config invalid: a route whose
ai-proxy-multiinstances 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.