Rate-limit stores
REST clients call theRateLimitStore methods to reserve work, observe response
headers, and record HTTP 429 penalties. Applications normally pass a store through
rest.rateLimitStore rather than calling these methods themselves.
Keep each store scoped to one API endpoint and credential. Keys do not include
that scope automatically. See REST behaviour.
MemoryRateLimitStore
Import fromtalos-fluxer or talos-fluxer/rate-limits.
new MemoryRateLimitStore(maxBuckets?) defaults to 1,000 bucket and alias entries.
The capacity must be a positive integer. See the source.
Share one instance across REST clients using the same API and credential:
reserve() atomic and namespace its state by API and credential.
The optional canPipeline(key) hint enables concurrent reads within the REST
client’s concurrency bound. Omit it to retain sequential requests on each route.
The in-memory store wakes queued reservations when fresh quota arrives and
admits one probe after a window expires, avoiding simultaneous unreserved bursts.
IPCRateLimitStore
Import fromtalos-fluxer/node. Construct
new IPCRateLimitStore(port, maxPending?) on the worker side of a Node
MessageChannel. Pending RPC capacity defaults to 1,000. See
the source.
The parent must call
serveRateLimits(otherPort, store, maxPending?). That
function returns a cleanup callback. close() disposes the store’s listeners;
it does not close the underlying port.
Pending RPC overflow and a closed coordinator reject with ordinary Error
objects. Use the parent and
worker examples for port transfer and supervision.