AlinsRan commented on PR #13666: URL: https://github.com/apache/apisix/pull/13666#issuecomment-4965737588
### Behaviour notes for reviewers Two things this changes that are worth naming explicitly, both a consequence of routing single-node `least_conn` upstreams through the balancer instead of the fast path (they have to be counted, or a 1→N scale out sees the surviving node as empty — the topology a k8s deployment or a discovery service starts from). **1. A single-node `least_conn` upstream now pays the picker path.** `lrucache_server_picker` + `lrucache_addr` + a size-1 heap peek/update per request, instead of returning `up_conf.nodes[1]` directly. It is the same cost every multi-node upstream already pays and it is required for correctness, but it is a real (small) regression on the hottest path for the most common topology. **2. Unbracketed IPv6 node hosts.** A single-node upstream used to bypass `parse_addr` entirely; it no longer does for `least_conn`, so `"::1:1980"` now fails the way it already fails everywhere else. This is a pre-existing bug, not a new one — I verified on `origin/master` that a *two*-node upstream with unbracketed IPv6 hosts crashes identically (`balancer.lua:238: attempt to concatenate field 'port' (a nil value)`), for every balancer type. The Admin API rejects such nodes (`upstream.lua` `check_schema`: "IPv6 address must be enclosed with '[' and ']'"); only the DP-side check (`check_upstream_conf(in_dp = true)`) skips that validation, which is how a standalone/discovery config can still carry one. Worth fixing, but as its own change — the addr string built in `transform_node` needs to bracket IPv6, and that string is shared with chash and the health checker. Also: `least_conn` state is now shared per `(resource_key, priority)` per worker. Upstreams with no stable resource key — traffic-split inline upstreams, `ai-proxy-multi` instances, and (in the EE port) `conf_server` — take a private-state branch and keep the previous behaviour. -- 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]
