The 50 request limit applies per execute_in_parallel call, not per client (SDK requirements §12) #104

Summary

SDK requirements §12 asks for one client-level pool of at most 50 concurrent requests, shared by every endpoint, as a sliding window. sdk-php limits each parallel call on its own instead.

Current behavior

ClientBase::execute_in_parallel (src/ClientBase.php:181) builds a Guzzle EachPromise with 'concurrency' => Settings::MAX_CONCURRENT_REQUESTS (50, src/Settings.php:390), so every call is a sliding window of its own. Nothing is shared between calls. The fan-outs of Options and Stocks (src/Endpoints/Options.php:593 and :670, src/Endpoints/Stocks.php:572 and :665) each open one, so two of them running at once can put up to 100 requests in flight. A request made outside execute_in_parallel is not counted by any limit.

A call waits for all its requests before it returns, so two calls overlap only when the program runs them concurrently itself (fibers, an event loop) or in separate processes, which no per-client pool can bound. In a plain synchronous script the 50 holds today. This issue is about the client-level contract of §12.

Why it matters

The API's rate-limit docs say requests above 50 in flight get a 429 (Concurrent Request Limit). sdk-go, sdk-csharp, sdk-java and sdk-js keep one pool per client, shared by every request.

Proposal

Move the limit from the call to the client: one limit for the whole Client that every request draws from, single or fanned out. A retry waiting out its backoff should hold no slot, as in sdk-csharp, sdk-java, sdk-js and sdk-py.

The refusal above 50 was not reproduced in the live runs of the sdk-py change (120 simultaneous requests were all answered and none was refused), so it stands as documented, not as measured.

Context

Found while auditing the sibling SDKs for MarketDataApp/sdk-py#65, fixed in MarketDataApp/sdk-py#164.