Escape LIKE wildcards in operation-audit search so terms with % or _ match literally

[zjncs]

Motivation

The operation-audit search box passes the raw term straight into LIKE clauses over operator, resource_name and detail (MybatisPlusAuditRepository.findPage and the shared applyFilters used by summarize/exportLogs). Because % and _ are SQL LIKE wildcards:

• searching for an operator or topic name containing % (e.g. 100%) matches every row whose text merely ends with 100, and
• _ matches any single character,

so the audit page and its summary cards can report wildly wrong results for these inputs.

Changes

• Add a private escapeLike helper (same behaviour as the existing QueryHistoryService.escapeLike) and apply it to the search term in both findPage and applyFilters, so the page query, summarize aggregates and exportLogs all match the term literally.

Verification

MybatisPlusAuditRepositoryTest — two new tests:

• findPageEscapesLikeWildcardsInTheSearchTermTest: searching 100%_ok binds %100\%\_ok% instead of the unescaped pattern.
• summarizeEscapesLikeWildcardsInEveryAggregateQueryTest: every aggregate query built by summarize (result counts, distinct operators, both hotspot GROUP BYs, latest-at lookup) binds the escaped literal.

Before the fix both new tests fail; after it the class is green (11/11).

$ mvn -f server/pom.xml test -Dtest='MybatisPlusAuditRepositoryTest'
(before) Tests run: 11, Failures: 2, Errors: 0
(after)  Tests run: 11, Failures: 0, Errors: 0

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

Summary

Fixes LIKE wildcard escaping in operation-audit search so that % and _ in user-typed search terms are matched literally rather than interpreted as SQL patterns. The escapeLike() helper correctly escapes backslash first, then the two wildcards — this ordering prevents double-escaping. Tests verify both the escaped parameter value and the query wrapper behavior.

Clean, focused fix. LGTM.

---

Automated review by github-manager-bot

[lizhimins]

Closing as part of consolidating the LIKE-escape work. The escaping is needed, but this patch adds a private escapeLike copy in the audit repository (the third one across #4192 #4193 #4194), and the whole set relies on MySQL's implicit backslash escape character with no explicit ESCAPE clause — which is wrong on H2, where five tests in this suite run.

See #4236: we asked for the shared SqlLikeUtils version with an explicit ESCAPE clause, and that one should land first. Note also that #4191 moved findPage onto applyFilters, so the patch needs rebasing regardless.