Aias00 opened a new issue, #7914:
URL: https://github.com/apache/shenyu/issues/7914

   ### Current behavior / reproduction
   
   An explicit empty-string rule update is accepted and persisted by Admin, but 
the remaining fault-tolerance handlers do not replace/clear their previous 
state consistently.
   
   Executed against `fda742c48e7f553c9964cf74b36732326d0fde00` with each real 
handler, valid initial handles and then `rule.setHandle("")`:
   
   ```text
   Resilience4J: same previous cached handle remains; next doExecute throws 
NullPointerException in Resilience4JBuilder.build
   RateLimiter: same previous enforcement handle remains in CACHED_HANDLE
   Sentinel: handlerRule throws NullPointerException at 
sentinelHandle.checkData before updating state
   ```
   
   Gson returns null for this empty input; it does not produce an empty default 
handle. For Resilience4J, the registry is removed first but the cached handle 
is retained, and runtime reparses the new blank rule into null. Sentinel was 
seeded with a valid flow/degrade configuration before the blank update. No 
Redis server or live backend was needed to execute these handler/cache/request 
paths.
   
   ### Reachable path and locations
   
   Admin RuleServiceImpl only applies special handle validation to 
agent-gateway rules; its selective rule update writes a non-null empty string 
and publishes the updated rule. This report concerns an **explicit empty 
string**, not an omitted field in a partial update.
   
   - [Resilience4J handler removes registry, then ignores a null parsed cache 
value](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-plugin/shenyu-plugin-fault-tolerance/shenyu-plugin-resilience4j/src/main/java/org/apache/shenyu/plugin/resilience4j/handler/Resilience4JHandler.java#L54)
   - [Resilience4J runtime reparses and dereferences the 
handle](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-plugin/shenyu-plugin-fault-tolerance/shenyu-plugin-resilience4j/src/main/java/org/apache/shenyu/plugin/resilience4j/build/Resilience4JBuilder.java#L47)
   - [Rate-limiter rule 
update](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-plugin/shenyu-plugin-fault-tolerance/shenyu-plugin-ratelimiter/src/main/java/org/apache/shenyu/plugin/ratelimiter/handler/RateLimiterPluginDataHandler.java#L86)
   - [Sentinel rule update dereferences the parsed 
value](https://github.com/apache/shenyu/blob/fda742c48e7f553c9964cf74b36732326d0fde00/shenyu-plugin/shenyu-plugin-fault-tolerance/shenyu-plugin-sentinel/src/main/java/org/apache/shenyu/plugin/sentinel/handler/SentinelRuleHandle.java#L61)
   
   ### Expected behavior / suggested repair
   
   Define explicit-clear behavior for these plugins and apply it atomically to 
cached handles and enforcement registries. Evict/disable cleared state or 
reject the unusable update before persistence with a clear validation result; 
do not publish a configuration that becomes stale enforcement or a runtime NPE. 
Preserve omitted-field selective-update semantics. Add valid-to-empty, 
whitespace, default/no-op, removal and subsequent-valid-update regressions.
   
   ### Related existing issues
   
   This is a grouped follow-up to **closed #7759**, whose implemented scope was 
Request, Rewrite, ModifyResponse and ParamMapping handlers. Those fixes do not 
change the remaining fault-tolerance paths above. This is not a fresh-rule 
cache-miss report, and is not split into one issue per plugin. Medium severity; 
handler/cache behavior and the Resilience4J request failure were executed and 
independently source-reviewed.
   


-- 
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]

Reply via email to