The GitHub Actions job "CI" on rocketmq-dashboard.git/fix/acl-version-filter-v2 has failed. Run started by GitHub user unbridled-41 (triggered by unbridled-41).
Head commit for run: 95c42fe16fbe0687651199eed5b82c6e8611181d / unbridled-41 <[email protected]> fix(acl): apply the rule version filter the console sends The ACL rule table offers an "ACL 1.0 / ACL 2.0" selector, and the web client sends the picked value as `aclVersion` on `GET /api/acl/rules` (`web/src/pages/instance/acl.tsx:196`). No layer consumed it: the controller declared no `aclVersion` parameter, so Spring dropped the unknown query parameter, and `AclService.listRules` passed a hardcoded `null` in the repository's `acl_version` slot (`AclService.java:98`) — even though `MybatisPlusAclRepository.ruleQuery` already had the predicate (`.eq(StringUtils.hasText(aclVersion), "acl_version", aclVersion)`). Selecting a version therefore changed only the query string: the table kept every rule and the pagination total never shrank. The demo/mock path filters in the service layer, which is why the control looked like it worked. Observed before the fix with a real service between the controller and a mocked repository, for `GET /api/acl/rules?aclVersion=1.0`: Argument(s) are different! Wanted: findRulePage(null, null, null, null, "1.0", 1, 20) Actual invocations have different arguments at position [4]: findRulePage(null, null, null, null, null, 1, 20) -> at AclService.listRules(AclService.java:98) The filter now travels with the other rule filters: the controller binds it, the service forwards it to the repository, and the role-backed projection (Tencent), which has no `acl_version` column, filters it in memory beside the resource/scope/decision filters it already applied. Report URL: https://github.com/apache/rocketmq-dashboard/actions/runs/37087808779 With regards, GitHub Actions via GitBox
