unbridled-41 opened a new pull request, #5434:
URL: https://github.com/apache/rocketmq-dashboard/pull/5434
## Problem / Evidence
A rule created from the console is stored **disabled**, and nothing in the
dialog or the success toast says so — the rule never evaluates.
- `web/src/pages/ops/alerts.tsx:802-805` builds the create payload from the
form values only; the create modal (`:1103-1524`) has no `enabled` item at all,
only the aggregation field has an `initialValue`.
- The request DTO models it as a primitive boolean:
`ops/alert/AlertRuleRequestDTO.java:49` `private boolean enabled;` → `:79
.enabled(enabled)`. An omitted JSON field therefore deserialises to **false**,
and `MybatisPlusAlertRepository.java:343` writes
`entity.setEnabled(rule.isEnabled())` — so the insert stores `0` and the
column's `DEFAULT 1` (`db/schema.sql:309`) is never reached.
- Reproduction: `/ops/alerts` → 新建规则 → fill name / instance / metric /
threshold / duration / channel → create. The toast says the rule was created;
the list then shows the status switch **off**, and no alert is ever produced.
The surrounding code all points at "enabled by default" instead:
| Source | Value |
|---|---|
| `db/schema.sql:309` (`enabled`) | `DEFAULT 1` |
| `web/src/services/opsService.ts:252` (mock create) | `enabled: true` |
| `AlertRuleTransferService.java:76` (import) | preserves the file's value |
## Root cause / Fix
An enable choice was never exposed, so the payload fell through to the
primitive-boolean default. Send `enabled: true` for created rules:
```ts
const createPayload = { ...payload, enabled: true } as Partial<AlertRule>;
```
The edit path is deliberately untouched — it spreads `{ ...editingRule,
...payload }`, so a rule the operator disabled stays disabled through an edit.
## Priority & scoring
PRIORITY 70 = 影响 22 (a monitoring rule is created dead with no signal, on
the primary alerting workflow) + 波及 13 (alert rule create + everything that
consumes rule state) + 可复现 20 (deterministic) + 维护价值 15 (aligns the payload
with the schema default the mock already assumed).
FIX_CONFIDENCE 75: one field on the create payload; the alternative (adding
an explicit "enabled" switch to the dialog) is a larger product decision left
out of scope.
## Tests
```
cd web && npx vitest run src/pages/ops/__tests__/AlertsPage.test.tsx
```
- Red before the fix: `creates the rule enabled because the dialog has no
enable control` → `AssertionError: expected "vi.fn()" to be called with
arguments: [ ObjectContaining{…}, 'BUSINESS' ]` (the create call carries no
`enabled`).
- Green after: `Tests 30 passed (30)` — the new test drives the full create
dialog (name, instance, metric, operator, threshold, duration, channel) and
asserts `createAlertRule` receives `{ name: 'Lag guard', enabled: true }`.
- `npx tsc -b` clean; `npx eslint` on both files reports no errors.
## Risk
Low. Only the create payload gains a field; the update path, the toggle and
the bulk toggle are unchanged.
--
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]
