lizhimins commented on PR #6611: URL: https://github.com/apache/rocketmq-dashboard/pull/6611#issuecomment-6190308694
Closing in favour of #6619, which is now merged into `rocketmq-studio` as `f22a5521b`. The demo/real divergence is real and the fix is well targeted: mirroring the backend `validateEnvelope` (document, version 1, matching domain, 1..200 rules) inside the mock branch of `importAlertRulesTransfer` is exactly the right parity, and the tests are strong — each rejected envelope also asserts that neither domain's inventory changed, and the accepted-boundary case proves the imported rows are deep copies. Blocking issue: this branch carries commit `88ea027ee` from your own #6619, which shows up here as +7/-3 in `web/src/pages/settings/__tests__/CloudCredentialTab.test.tsx` and has nothing to do with alert import. Please rebase it out (together with the two `ci:`-prefixed commits, which are not CI changes) so this PR contains only the three alert-related files; if #6619 lands first, a re-sync makes this clean on its own. Two non-blocking notes: three of the four new service-level checks are unreachable from the page because `alerts.tsx` already rejects a wrong version/domain/non-array before calling the service — that is fine as defense in depth, but please point the literal `200` at the backend `MAX_RULES_PER_IMPORT` in a comment so the two layers cannot drift; and switching the file-wide `dataMode` mock to a mutable `vi.hoisted` flag plus `vi.resetModules()` changes how the 17 pre-existing cases in `opsService.test.ts` are instantiated, so keep an eye on future static imports there. -- 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]
