Aias00 opened a new issue, #7707: URL: https://github.com/apache/shenyu/issues/7707
### Current behavior The create API/service inserts scale rules as separate rows with unique IDs. `scale_rule.metric_name` has no unique constraint in the supported initialization schemas, and `ScaleRuleServiceImpl.create()` does not reject duplicate metric names. However, `ScaleRuleCache.initialize()` and `addOrUpdateRuleToCache()` key rules by metric name, silently retaining only the last rule for a metric. `MetricsMonitor.monitorMetrics()` evaluates only `getAllRules()` from that cache, so the runtime does not evaluate all successfully persisted enabled rules. ### Locations - [ScaleRuleCache.java:31–49](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-admin/src/main/java/org/apache/shenyu/admin/scale/monitor/subject/cache/ScaleRuleCache.java#L31) - [ScaleRuleServiceImpl.create():111–120](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/ScaleRuleServiceImpl.java#L111) - [MetricsMonitor.java:65–75](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-admin/src/main/java/org/apache/shenyu/admin/scale/monitor/subject/MetricsMonitor.java#L65) - [MySQL scale_rule schema](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/db/init/mysql/schema.sql#L2331); the H2 definition has the same lack of metric-name uniqueness. ### Trigger / validation Create two rules with different IDs/thresholds/sorts but the same metric name (e.g. `cpu_usage`). The API/schema accept them as separate rows, but only the last cached one is evaluated. Disabling or deleting the surviving rule does not restore the other persisted rule to the cache. A standalone probe compiled the current cache, initialized two independent DOs with IDs a/b and the same metric, and then removed b by ID: ```text INPUT_RULES=2 CACHE_RULES=1 SURVIVING_ID=b AFTER_DELETING_B_CACHE_RULES=0 REMAINING_DB_RULE_ID=a ``` Database acceptance is established by schema/service inspection, not a full deployed Admin request. An independent reviewer confirmed the cache key, persistence constraints and monitor consumer. ### Impact / priority **P2 / Medium; high confidence in the persistence/runtime mismatch.** Operators can save enabled rules that never participate in scaling decisions. At startup the winner depends on initialization ordering; after edits it depends on the last cache update. ### Suggested fix / contract decision Make persistence, API validation and runtime identity consistent. If multiple rules per metric are supported, store them by rule ID (or group a list per metric) and preserve all during rename/delete. If one rule per metric is intended, reject duplicates before success and enforce the uniqueness invariant in the database, including a migration strategy for existing duplicates. Either contract should avoid silently accepting then dropping a rule. ### Related existing work #6972 addresses deletion not evicting a rule by its primary key, #6710 premature cache publication before commit, and #6623 double-generated IDs. Those do not address accepted same-metric rows collapsing into a single runtime entry. Searched complete issue titles and live ScaleRuleCache/duplicate-metric queries. ### Reviewed revision Apache ShenYu 2.7.2-SNAPSHOT, `master@66d7d954ca37d651a5ad916f988a8081157a7ab4`. Unit-test and CI issue categories excluded. -- 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]
