Description
Both removeRule implementations gate the cache eviction behind Optional.ofNullable(ruleData.getHandle()).ifPresent(s -> CACHED_HANDLE.get().removeHandle(...)). If the rule-deletion event carries only the rule id (handle == null), ifPresent never fires and the cached SignRuleHandler / CryptorRuleHandler keyed by selectorId_ruleId is never evicted. Contrast JwtPluginDataHandler.removeRule:56-58, KeyAuthPluginDataHandler.removeRule:45-47, and BasicAuthPluginDataHandler.removeRule:55-57, which all call removeHandle unconditionally.
Location
shenyu-plugin/shenyu-plugin-security/shenyu-plugin-sign/src/main/java/org/apache/shenyu/plugin/sign/handler/SignPluginDataHandler.java:47-49shenyu-plugin/shenyu-plugin-security/shenyu-plugin-cryptor/src/main/java/org/apache/shenyu/plugin/cryptor/handler/AbstractCryptorPluginDataHandler.java:60-62
Impact
Stale rule-handle objects accumulate in the CommonHandleCache indefinitely (memory leak). For cryptor, a stale CryptorRuleHandler (containing decryptKey/encryptKey/strategyName/fieldNames/way) persists; for sign, a stale SignRuleHandler (the signRequestBody flag) persists.
Suggested fix
Drop the getHandle() guard and call CACHED_HANDLE.get().removeHandle(CacheKeyUtils.INST.getKey(ruleData)) unconditionally (as JWT/key-auth/basic-auth already do), guarding only on ruleData itself.
Related existing
None — distinct from NEW-06 (#6772, removeRule handle guard), which lists redirect/rewrite/param-mapping/modify-response/context-path. The sign and cryptor data handlers are the same bug class but were omitted from NEW-06's file list; they are separate plugins with separate cached handle types.
Description
Both
removeRuleimplementations gate the cache eviction behindOptional.ofNullable(ruleData.getHandle()).ifPresent(s -> CACHED_HANDLE.get().removeHandle(...)). If the rule-deletion event carries only the rule id (handle == null),ifPresentnever fires and the cachedSignRuleHandler/CryptorRuleHandlerkeyed byselectorId_ruleIdis never evicted. ContrastJwtPluginDataHandler.removeRule:56-58,KeyAuthPluginDataHandler.removeRule:45-47, andBasicAuthPluginDataHandler.removeRule:55-57, which all callremoveHandleunconditionally.Location
shenyu-plugin/shenyu-plugin-security/shenyu-plugin-sign/src/main/java/org/apache/shenyu/plugin/sign/handler/SignPluginDataHandler.java:47-49shenyu-plugin/shenyu-plugin-security/shenyu-plugin-cryptor/src/main/java/org/apache/shenyu/plugin/cryptor/handler/AbstractCryptorPluginDataHandler.java:60-62Impact
Stale rule-handle objects accumulate in the
CommonHandleCacheindefinitely (memory leak). For cryptor, a staleCryptorRuleHandler(containingdecryptKey/encryptKey/strategyName/fieldNames/way) persists; for sign, a staleSignRuleHandler(thesignRequestBodyflag) persists.Suggested fix
Drop the
getHandle()guard and callCACHED_HANDLE.get().removeHandle(CacheKeyUtils.INST.getKey(ruleData))unconditionally (as JWT/key-auth/basic-auth already do), guarding only onruleDataitself.Related existing
None — distinct from NEW-06 (#6772,
removeRulehandle guard), which lists redirect/rewrite/param-mapping/modify-response/context-path. The sign and cryptor data handlers are the same bug class but were omitted from NEW-06's file list; they are separate plugins with separate cached handle types.