Introduces a new SkRateLimiterService
which uses Leaky Bucket logic instead of Misskey's "time-box" rate limits. All internal servers are updated to use the new limiter, and FileServerService
is patched to respect role-based rate limit scaling.
Additionally, all API endpoints now return detailed rate limit headers. The new headers are:
X-RateLimit-Remaining
- number of calls that can be made without triggering the rate limit. Will be zero if the limit is already exceeded, or will be exceeded by the next request.X-RateLimit-Remaining: 1
.X-RateLimit-Clear
- time in seconds required to completely clear the rate limit "bucket".X-RateLimit-Clear: 1.5
.X-RateLimit-Reset
- if the rate limit is currently exceeded, then contains the number of seconds to wait before retrying. Clients should delay for at least this long before retrying their request. Only included if the rate limit has been exceeded.X-RateLimit-Reset: 0.755
.Retry-After
- like X-RateLimit-Reset
, but measured in seconds (rounded up). Preserved for backwards compatibility, and only included if the rate limit has been exceeded.Retry-After: 2
.Note: rate limit headers are not standardized, except for Retry-After
. Header meanings and usage have been devised by adapting common patterns to work with a leaky bucket model instead. Some helpful resources for context, ideas, and prior work:
By submitting this merge request, you agree to follow our Contribution Guidelines