Skip to content

rateLimit getter/setter on core BaseExchange not exposed in either SDK #996

Description

@realfishsam

Gap

BaseExchange in core exposes a rateLimit getter and setter that controls the millisecond delay between successive API requests. Setting it reconfigures the internal Throttler live, allowing callers to dynamically adjust throughput at runtime without reconstructing the exchange. Neither SDK exposes this getter or setter.

Core

core/src/BaseExchange.ts lines 533–545

private _rateLimit: number = 1000;

get rateLimit(): number {
    return this._rateLimit;
}

set rateLimit(value: number) {
    this._rateLimit = value;
    this._throttler = new Throttler({
        refillRate: 1 / value,
        capacity: 1,
        delay: 1,
    });
}

Default value is 1000 ms. Setting it to a lower value increases request throughput; setting it higher throttles calls more aggressively. The setter is the only way to change the throttle rate after construction.

TypeScript SDK

sdks/typescript/pmxt/client.ts — no rateLimit getter or setter anywhere in the Exchange class or its subclasses.

grep -n "rateLimit" sdks/typescript/pmxt/client.ts → zero results.

Python SDK

sdks/python/pmxt/client.py — no rate_limit property anywhere in the Exchange class.

grep -n "rate_limit\|rateLimit" sdks/python/pmxt/client.py → zero results.

Evidence

grep -n "rateLimit" core/src/BaseExchange.ts → lines 489 (usage), 533 (field), 535 (getter), 539 (setter), confirming this is part of the core's public exchange interface.

Searching both SDK source trees for any form of rateLimit or rate_limit returns zero results, confirming neither getter nor setter is wired up.

Impact

SDK users cannot inspect or modify the request throttle rate at runtime. Use cases that require dynamic rate adjustment — backing off when a venue returns 429s, ramping up throughput in batch jobs, or matching rate limits per API tier — must either reconstruct the exchange client entirely or make raw HTTP calls to the sidecar with a manually managed delay. There is also no way to read back the current throttle setting to verify configuration or log it for debugging.


Found by automated Core-to-SDK surface coverage audit

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions