Aias00 opened a new issue, #8019: URL: https://github.com/apache/shenyu/issues/8019
### Is there an existing issue for this? - [x] I have searched the existing issues. ### Current Behavior Divide selects the first upstream from the rule's stable/canary label partition, using the full healthy pool. HTTP failover retries instead call findUpstreamListBySelectorId(selectorId), which applies the legacy pool policy and does not retain the label partition selected for this request. Thus a stable request may retry against a canary node, or a canary request may retry outside its canary pool. When legacy gray nodes exist, the retry pool may contain only those gray nodes even though another healthy stable node exists. Suggested severity: High: request routing isolation can be violated during failover. ### Expected Behavior Every failover attempt must honor the request's resolved label partition and explicit fallback policy. Refreshing health/topology must not remove routing constraints. Keep legacy rules without Canary configuration working as before. A backend error must not silently trigger a cross-partition fallback that the rule only permits for an initially empty canary pool. ### Steps To Reproduce 1. Configure one Divide selector with stable nodes S1/S2 and canary node C1. Assign matching release labels; mark C1 as legacy gray to make pool differences deterministic. 2. Configure a Canary-aware rule that selects STABLE (for example enabled=false with explicit stable labels, or a decision excluding this request), with retry > 0 and the FAILOVER retry strategy. 3. Make the first stable attempt fail before a response is committed. Keep S2 healthy. 4. Follow the HTTP client's failover selection: it reads the legacy gray-exclusive pool and may call C1 instead of S2. 5. Also exercise a selector without legacy gray flags: retries can select any label partition from the unfiltered pool. These are proposed regression scenarios derived from the code path, not an executed network reproduction. ### Environment - ShenYu: master / 2.7.2-SNAPSHOT, commit `34f2ed036747936a5e28aea2c94cd9b3cddcce47`. - Evidence: source inspection. The reporting environment has no available Java runtime, so no Maven/JUnit execution or live reproduction is claimed. - These issues concern existing runtime behavior, not the proposed plugin DAG implementation. ### Debug logs No runtime logs captured; this report is based on the source paths below. ### Code evidence - [Initial partition selection](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-divide/src/main/java/org/apache/shenyu/plugin/divide/DividePlugin.java#L116-L154) - [Failover reloads the legacy pool without partition filtering](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-httpclient/src/main/java/org/apache/shenyu/plugin/httpclient/DefaultRetryStrategy.java#L117-L140) - [Full versus legacy gray-exclusive pool lookup](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-loadbalancer/src/main/java/org/apache/shenyu/loadbalancer/cache/UpstreamCacheManager.java) - [Existing Divide-only tests do not execute the HTTP retry stage](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-divide/src/test/java/org/apache/shenyu/plugin/divide/DivideCanaryRoutingTest.java) ### Suggested fix direction Carry the resolved partition constraints in an explicit request-scoped routing context and reapply them to the latest healthy pool on every failover attempt, before breaker filtering/load balancing. Preserve whether initial fallback to STABLE was actually resolved; do not silently recompute a different partition on each retry. ### Acceptance criteria - Stable and canary requests never cross their resolved partitions during failover. - Retry selects a remaining healthy same-partition node, including when legacy gray flags coexist. - Exhausted partitions fail explicitly instead of escaping into another pool. - Cover CURRENT/FAILOVER and relevant fixed/exponential retry strategies; verify legacy no-Canary behavior. ### Related work Canary routing was introduced by #7963. This is independent of plugin-graph orchestration. -- 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]
