Aias00 opened a new issue, #7981:
URL: https://github.com/apache/shenyu/issues/7981
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current Behavior
A URI-only selector can be cached by plugin/path when it is the only
selector matching the current request, even though another selector depends on
dynamic request attributes and could win on a subsequent request with the same
path.
`cacheSelectorData` checks only the winning selector's conditions. It does
not establish that the winner remains correct across the entire candidate set
for all requests sharing the cache key. A positive cache hit then bypasses
candidate evaluation.
Consequently, warming the cache with an ordinary request changes the routing
result of an otherwise identical VIP request. This is a correctness defect, not
only a cache hit-rate concern.
### Expected Behavior
With configuration unchanged, enabling or warming a match cache must not
change the selected selector/rule for a given request. A path-only result must
be reused only if the relevant candidate set cannot produce a different winner
due to omitted request attributes.
### Steps To Reproduce
1. Enable a concrete AbstractShenyuPlugin test plugin and default match
caches.
2. Configure two enabled CUSTOM_FLOW selectors with AND matching:
- Generic: `uri = /x`.
- VIP: `uri = /x` AND `header X-Tenant = a`.
3. Set continued=false for both so the test isolates selector matching and
uses the default rule.
4. Execute GET /x with X-Tenant=b. Generic is the only match and is cached.
5. Execute GET /x with X-Tenant=a. Observed: Generic executes again.
6. Clear only the selector match cache and repeat step 5. Observed: VIP
executes, as required by its larger AND-condition count.
Executed via a recording AbstractShenyuPlugin subclass, real
BaseDataCache/MatchDataCache, Spring MockServerWebExchange and
execute(...).block():
```text
ordinary request warms cache: generic:default_rule
VIP request after warmup: generic:default_rule
same VIP request after clear: special:default_rule
```
### Environment
ShenYu master, 2.7.2-SNAPSHOT, commit
`862f5e37e894bd8cef85ef540a8629f313e9ecdf`, Java 17. This is an executed
in-process reproduction, not a deployed HTTP integration test.
### Anything else?
- [Positive selector cache
eligibility](https://github.com/apache/shenyu/blob/862f5e37e894bd8cef85ef540a8629f313e9ecdf/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/AbstractShenyuPlugin.java#L157-L177)
- [Cached selector accepted before
matching](https://github.com/apache/shenyu/blob/862f5e37e894bd8cef85ef540a8629f313e9ecdf/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/AbstractShenyuPlugin.java#L93-L104)
- The analogous positive rule-cache eligibility should also be covered by
regression tests; the executed reproduction above isolates selectors.
- #7977 concerns caching a miss. This issue concerns caching a successful
generic match that later shadows a more specific dynamic candidate.
- #7976 concerns rule-cache isolation across selectors, a separate issue.
Adding a single header to the key is not a general fix: competing candidates
can depend on method, query, cookies, domain or other inputs. Conservative
candidate-set cache eligibility or dependency-aware cache keys should preserve
matching semantics.
--
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]
