thswlsqls opened a new issue, #39206: URL: https://github.com/apache/shardingsphere/issues/39206
## Bug Report ### Which version of ShardingSphere did you use? master @ 80e6541 ### Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy? Both (kernel-level) ### Expected behavior When `ALTER ENCRYPT RULE` removes a column's assisted-query or like-query, the auto-generated encryptors backing them should be dropped from the persisted configuration, leaving no orphaned encryptors. ### Actual behavior The auto-generated `assist_*` / `like_*` encryptors stay in the persisted configuration as orphans after the columns referencing them are removed by ALTER. ### Reason analyze (If you can) `AlterEncryptRuleExecutor.buildToBeDroppedRuleConfiguration()` ignores its `toBeAlteredRuleConfig` parameter and runs `UnusedAlgorithmFinder.findUnusedEncryptor(rule.getConfiguration())` against the pre-alter configuration. There every encryptor is still referenced, so the finder always returns empty and nothing is dropped. The sibling `AlterMaskRuleExecutor` already computes the post-alter in-use set correctly, and `DropEncryptRuleExecutor` is also correct; only the ALTER encrypt path is broken. ### Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc. Create an encrypt rule on a column with assisted-query and like-query, then `ALTER ENCRYPT RULE` the same column keeping only the cipher. The `assist_*` / `like_*` encryptors remain in the persisted rule. ### Example codes for reproduce this issue (such as a github link). N/A -- 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]
