Skip to content

fix: correct ruleset type_ident registry in docs - #313

Closed
ysyneu wants to merge 2 commits into
mainfrom
fix/store-ruleset-type-desc
Closed

fix: correct ruleset type_ident registry in docs#313
ysyneu wants to merge 2 commits into
mainfrom
fix/store-ruleset-type-desc

Conversation

@ysyneu

@ysyneu ysyneu commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

What

The type_ident field on the store-ruleset endpoints (/monit/store/ruleset/create, /monit/store/ruleset/list, and the corresponding schemas) was documented as a datasource type identifier with prometheus as the example. That's the wrong registry.

Why it's wrong

In monit-webapi, ruleset type_ident is validated against the store type registry, not the datasource registry:

  • logic/logic_store.go (CreateRuleset and RulesetList) both call model.NewStoreTypeRepo(ctx).GetByIdent(ident), which reads the store_types table.
  • store_types is seeded (misc/sql/schema.sql) with exactly: mysql, redis, elasticsearch, kafka, blackbox, mongodb, postgresql, os, minio, etcd. prometheus is not among them under any casing.
  • prometheus belongs to a separate ds_types table, surfaced by the unrelated POST /monit/rule/dstypes endpoint (used by alert-rule/datasource fields elsewhere in the same spec).

So the previously documented example (type_ident: "prometheus") could never pass validation on this endpoint.

Change

  • api-reference/openapi.en.json / openapi.zh.json: corrected every ruleset-scoped reference to the wrong registry —
    • the 3 type_ident field descriptions on the ruleset request/response schemas (now say "store type", example redis)
    • the /monit/store/ruleset/list operation description ("for a given store type")
    • StoreRulesetListRequest's object-level description ("Filter rulesets by store type")
    • every request/response example under the ruleset paths that used the invalid type_ident: "prometheus" value, changed to redis
      Left every "Datasource type identifier..." string elsewhere in the file untouched — those belong to the actual datasource/rule endpoints (POST /monit/rule/dstypes, Allowed: prometheus, loki, mysql, ...), where prometheus is correct. Re-grepped both full files for datasource/数据源/Datasource after the change: no remaining hit falls under the ruleset paths or schemas.
  • en/monitors/rule-repository/rule-repository.mdx and zh/monitors/rule-repository/rule-repository.mdx: the Rule Repository console page documents this same feature (the "New Ruleset" button maps to /monit/store/ruleset/create) and repeated the same wrong registry name and Prometheus example — corrected consistently.

Ran the repo's scripts/lint_openapi.py: OK: 12 spec files, no violations.

No tooling, scripts, or validation added — text correction only.

ysyneu added 2 commits August 25, 2026 07:23
The store-ruleset endpoints validate `type_ident` against the store
type registry (`store_types`: mysql, redis, elasticsearch, kafka,
blackbox, mongodb, postgresql, os, minio, etcd), not the datasource
type registry used by other monitor endpoints. `prometheus` is a
datasource type, not a store type, and was never a valid value here.

Update the three affected field descriptions in openapi.en.json and
their Chinese counterparts in openapi.zh.json to name the correct
registry, with `redis` as a valid example. Also correct the Rule
Repository console docs (en/zh), which described the same feature
using the wrong registry name and a `Prometheus` example.
Three more spots in the store-ruleset section of both openapi specs
still named the wrong registry or used an invalid example value:

- The `/monit/store/ruleset/list` operation description said "datasource
  type" instead of "store type".
- `StoreRulesetListRequest`'s object-level description said "Filter
  rulesets by datasource type" while its own `type_ident` property
  already said "store type" — self-contradictory.
- Every request/response example under the ruleset paths used
  `type_ident: "prometheus"`, which fails validation since `prometheus`
  is not a member of the store type registry. Changed to `redis`.

No other "datasource" reference remains under the ruleset paths or
schemas in either file; every other occurrence in the specs belongs to
the actual datasource/rule endpoints, where it is correct.
@ysyneu ysyneu closed this Aug 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant