Repository navigation
include rate limit groups in platform API Classes for dynamic api key fetching across all configured instances #294
Description
breakout issue for this specific part of the overall "key handling improvement" workflow, initially defined in #71
key limiting:
#71 suggests we add a "platform features" column to the worker_oauth table where we store API keys. This would be for storing key pseudo-platforms (IE: the different request limits for each key type - gor github, these would be
restandgraphql) these values would be used by keyman for rate limiting.For the purposes of this issue, I would call this "rate limit groups" instead, and i think they belong in the internal implementation, alongside other information like the platform name/type, rather than in a DB table, since they are basically fixed information that changes with the API (and should therefore live in the implementation code).
Originally posted by @MoralCode in #293
This should be done as part of the code implementing each platforms API (and integrated into keyman so workers can fetch the right API keys/groups for what they are doing)
Activity
MoralCode commentedon Jul 3, 2026
After thinking about this while:
The API client classes are going to depend on the domain name (for the base url and also potentially for the rate limit group name to pass to
KeyClient)the base domain for an instance and the instance itself should be able to uniquely determine each other, so that makes things easy.
The API path I believe is going to uniquely determine the rate limit group to use for each query (is it a REST, graphql, or some subset of rest), so that can be a static-ish map within each client class (which will also need to be externally looked up for the key-loading).
KeyClient.request()already supports sending a differentplatform(rate limit group) for each request.Tasks will need to do a lookup for the instance at the start to initialize the client access class with the domain name.
That seems reasonable enough
[-]include rate limit groups in platform API implementation[/-][+]include rate limit groups in platform API Classes for dynamic api key fetching across all configured instances[/+]