btlqql opened a new pull request, #7140:
URL: https://github.com/apache/rocketmq-dashboard/pull/7140
## What is the purpose of the change
In Mock mode the alert-rule store accepts a second rule whose evaluation
fields
match an existing rule, while the REST service rejects it:
`AlertService#rejectDuplicateSemanticRule`
answers 409 "An alert rule with the same evaluation conditions already
exists: <existing name>".
`createAlertRule` in `web/src/services/opsService.ts` pushed the new rule
into
`alertRulesState` without any such check, so Mock mode reported success and
stored two
identically-evaluating rules, hiding a conflict the real control plane
reports. The mock create
path now builds the same evaluation fingerprint as the server's
`AlertRuleSemanticFingerprint` (domain, instance, metric, upper-cased
operator, threshold with the
"%"-as-fraction rule for ratio metrics, lower-cased duration, aggregation
defaulting to `LAST`,
window, consumer group, topic, consecutive samples defaulting to `1`) and
rejects a match with the
server's message and the existing rule's name. The display name is not part
of the fingerprint, so
a different name no longer makes an identical rule distinct; public
behaviour of the REST path is
untouched.
## Brief changelog
- `web/src/services/opsService.ts`: added the fingerprint/error helpers and
the duplicate check in the Mock branch of `createAlertRule`.
- `web/src/services/opsService.test.ts`: added `rejects a mock alert rule
that repeats an existing evaluation fingerprint` (same fields under a new name,
case/whitespace normalisation, `%`-vs-fraction ratio thresholds, a distinct
threshold still accepted) and gave the two existing Mock create calls distinct
metrics, since they previously created rules with identical empty evaluation
fields; their assertions are unchanged.
## Verifying this change
- red: `cd web && npx vitest run src/services/opsService.test.ts` -> `FAIL
src/services/opsService.test.ts > ops service mock data > rejects a mock alert
rule that repeats an existing evaluation fingerprint` / `AssertionError:
promise resolved "{ id: 1792425895761, …(10) }" instead of rejecting`; `Test
Files 1 failed (1)`, `Tests 1 failed | 16 passed (17)` (log: `mockdup-red.log`)
- green: same command -> `✓ src/services/opsService.test.ts (17 tests)`,
`Test Files 1 passed (1)`, `Tests 17 passed (17)` (log: `mockdup-green.log`)
- regressions run: `npx vitest run src/services/opsService.test.ts
src/pages/ops/__tests__/AlertsPage.test.tsx
src/pages/ops/__tests__/AlertsTestResultResidue.test.tsx
src/pages/ops/__tests__/alerts.test.ts
src/pages/ops/__tests__/alertRulePayload.test.ts src/api/ops.test.ts
src/api/alertRules.test.ts` -> `Tests 1 failed | 92 passed (93)`; the single
failure is `AlertsPage.test.tsx > creates the rule enabled because the dialog
has no enable control`, which hit the 20s per-test limit on a loaded machine
(that file mocks this service entirely) and passes when re-run alone: `Tests 1
passed | 37 skipped (38)`, 17.5s. `npx tsc -b` -> exit 0. `npx eslint
src/services/opsService.ts src/services/opsService.test.ts` -> exit 0.
## Checklist
- [x] one issue, one PR: Fixes #7078
- [x] regression test added
- [x] targeted suites re-run
Not verified here: no live Studio backend or database was used, so the
fingerprint mirror was
checked against `AlertRuleSemanticFingerprint`/`AlertService` by reading the
Java sources rather than
by comparing responses; `web/src/services/opsService.ts` update paths were
left alone (the issue is
scoped to Mock creation); no full `npm test` run of the whole web suite.
--
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]
