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
Gap
BaseExchangein core exposes arateLimitgetter and setter that controls the millisecond delay between successive API requests. Setting it reconfigures the internalThrottlerlive, allowing callers to dynamically adjust throughput at runtime without reconstructing the exchange. Neither SDK exposes this getter or setter.Core
core/src/BaseExchange.tslines 533–545Default value is
1000ms. 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— norateLimitgetter or setter anywhere in theExchangeclass or its subclasses.grep -n "rateLimit" sdks/typescript/pmxt/client.ts→ zero results.Python SDK
sdks/python/pmxt/client.py— norate_limitproperty anywhere in theExchangeclass.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
rateLimitorrate_limitreturns 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