The GitHub Actions job "CI" on rocketmq-dashboard.git/fix/search-like-escapes has failed. Run started by GitHub user unbridled-41 (triggered by unbridled-41).
Head commit for run: 85b39ed37ec3ef0cc28846df2417dae150a7b2ed / unbridled-41 <[email protected]> fix(search): match LIKE metacharacters literally in every text search Four search paths passed the user's text straight into a MyBatis-Plus `.like()`, so `%` and `_` kept their pattern meaning: - audit log search (operator / resource_name / detail); - ACL user search (username / access_key) and ACL rule search (principal / resource); - data-source search in settings (json); - studio user search (username). The result is over-matching, not just noise: `svc_prod` also returns `svcXprod`, a lone `%` matches every row, and `%DLQ%group` matches anything containing the literals. RocketMQ names routinely contain `_` and `%` (topic_a, GID_prod-1, %DLQ%), so this is the common case rather than an edge case. QueryHistoryService and MybatisPlusAiConversationRepository already escape the term — the second one notes "a shared util is tracked separately upstream". Add that util and route the four unescaped paths (and the two existing private copies) through it, so the escaping rule lives in one place. Tested: - LikePatternsTest: escaping of `%`, `_`, and the escape character itself, plain text and absent filters. - MybatisPlusAuditRepositoryTest, MybatisPlusAclRepositoryTest, MybatisPlusSettingsRepositoryTest: each asserts the bound LIKE parameter (e.g. `%topic\_a%`). With the escaping removed the three suites fail 4 tests. - QueryHistoryServiceTest and AiTimelineRepositoryTest keep passing unchanged after their private copies move to the util, which pins the equivalence. - 139 tests across the affected suites pass; checkstyle clean. Report URL: https://github.com/apache/rocketmq-dashboard/actions/runs/37088758831 With regards, GitHub Actions via GitBox
