Frun1na opened a new issue, #4766:
URL: https://github.com/apache/rocketmq-dashboard/issues/4766
### Which Documentation
`docs/studio-native-alerting-design.md` — the §APIs endpoint list.
### What Is Wrong
The list was written before the implementation and never updated; six of its
eight lines describe
calls that do not exist:
- The rule endpoints are documented as `GET/POST/PUT .../{id}/test`, but
`AlertRuleController` /
`ClusterAlertRuleController` have no `PUT` mapping; listing is `GET
.../page`, writes are
`POST .../create` and `POST .../update`, and `test` takes the full rule
body with no `{id}` path
variable.
- The system-alert list is documented with `status` / `severity` / `page`
parameters, but
`SystemAlertController.listAlerts` accepts `level` / `domain` /
`instanceId` / `transition` — the
documented names are optional request parameters, so they would be
silently ignored — and
pagination lives at `GET /api/system-alerts/page`.
- `acknowledge` is documented as `POST /api/system-alerts/{id}/acknowledge`,
but the id goes in the
body (`AcknowledgeSystemAlertDTO`).
- The metric catalog is documented as `/api/alert-metric-catalog`; the
controller maps
`/api/native-alert-metrics`.
- The text says both rule menus delegate to `AlertRuleService`; the class is
`AlertService`, and no
`AlertRuleService` exists anywhere in the tree.
`/api/alert-silences` and `/api/alert-collector-status` were verified and
are correct.
A client integrating against this list would hit 404s or silently
ineffective filters on every rule
and system-alert call.
### Suggested Change
Align the list with the controllers (the linked PR does this).
Opened PR #4765 for this.
--
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]
