Problem
The Admin API OpenAPI schema for inline rate_limit includes rps and rph because the Rust RateLimit struct has those fields.
However, the actual validation schema used by Admin API model/API-key writes only allows:
rpmrpdtpmtpdconcurrency
For models and API keys, crates/aisix-core/src/models/schema.rs defines the inline rate_limit schema with additionalProperties: false and omits rps / rph. The Admin API handlers call validate_model / validate_apikey before storing resources, so a request body using rate_limit.rps or rate_limit.rph is rejected even though the generated OpenAPI advertises those fields.
Why this matters
The API reference suggests users can configure per-second or per-hour inline request limits on models or caller API keys, but the Admin API rejects those fields.
Shared RateLimitPolicy resources do support request-count windows for second, minute, and hour, but those are not exposed through the self-hosted Admin API resource routes.
Suggested direction
Fix validation, not OpenAPI.
RateLimit already defines rps and rph, the generated schema advertises them, and the data plane has native request-count windows for second/hour. The mismatch appears to be that the hand-written Admin API validation schema for inline model/API-key rate_limit was not updated.
Recommended fix:
- Add
rps and rph to the model/API-key validation schema.
- Add tests proving
rate_limit.rps and rate_limit.rph are accepted for models and API keys.
- Keep the generated OpenAPI
RateLimit schema as-is.
Problem
The Admin API OpenAPI schema for inline
rate_limitincludesrpsandrphbecause the RustRateLimitstruct has those fields.However, the actual validation schema used by Admin API model/API-key writes only allows:
rpmrpdtpmtpdconcurrencyFor models and API keys,
crates/aisix-core/src/models/schema.rsdefines the inlinerate_limitschema withadditionalProperties: falseand omitsrps/rph. The Admin API handlers callvalidate_model/validate_apikeybefore storing resources, so a request body usingrate_limit.rpsorrate_limit.rphis rejected even though the generated OpenAPI advertises those fields.Why this matters
The API reference suggests users can configure per-second or per-hour inline request limits on models or caller API keys, but the Admin API rejects those fields.
Shared
RateLimitPolicyresources do support request-count windows forsecond,minute, andhour, but those are not exposed through the self-hosted Admin API resource routes.Suggested direction
Fix validation, not OpenAPI.
RateLimitalready definesrpsandrph, the generated schema advertises them, and the data plane has native request-count windows for second/hour. The mismatch appears to be that the hand-written Admin API validation schema for inline model/API-keyrate_limitwas not updated.Recommended fix:
rpsandrphto the model/API-key validation schema.rate_limit.rpsandrate_limit.rphare accepted for models and API keys.RateLimitschema as-is.