Splitting up my subscriptions across multiple websockets seems to have resolved the issue. I have one process using my old code, a it has crashed about 1x per hour on "subscription buffer overflow". The process using the multiple websockets has only crashed once in about 4 hours of running due to no data checks failing (but this occasionally happened to me before so I can't say this is any worse).
Splitting up my subscriptions across multiple websockets seems to have resolved the issue. I have one process using my old code, a it has crashed about 1x per hour on "subscription buffer overflow". The process using the multiple websockets has only crashed once in about 4 hours of running due to no data checks failing (but this occasionally happened to me before so I can't say this is any worse).
if you have 1 million messages in your queue and they come in faster than you can process then you can be processing messages that are hours old
if you have 1 million messages in your queue and they come in faster than you can process then you can be processing messages that are hours old
One should definitely queue WS messages and handle them on another thread. But you still need the same amount of compute regardless.
One should definitely queue WS messages and handle them on another thread. But you still need the same amount of compute regardless.
Anyone else notice some weird lag issues that started at 5 pm Eastern?
Anyone else notice some weird lag issues that started at 5 pm Eastern?
I just had a fill reach me 21 seconds late on the WS 😂 so...yes
I just had a fill reach me 21 seconds late on the WS 😂 so...yes
getting bad OB data rn
getting bad OB data rn
You have been for the last 45 minutes
You have been for the last 45 minutes
yeah, it stopped for a second, now its bad again
yeah, it stopped for a second, now its bad again
who pushed to prod on a friday afternoon
who pushed to prod on a friday afternoon
ConnectionError: [Errno 9] Bad file descriptor
ConnectionError: [Errno 9] Bad file descriptor
Hi — I’m seeing a persistent 429 specifically on GET /trade-api/v2/markets.
My authenticated GET /account/limits currently reports:
* Tier: Basic
* Read bucket: 200 capacity / 200 refill rate
* Estimated /markets cost: 10 tokens
I initially had an overly deep paginated scanner, but I have since reduced it substantially and added defensive backoff:
* Normal scan: max 5 pages, 200 markets/page, ~50 estimated tokens
* Post-429 probe: exactly 1 page, ~10 estimated tokens
* Exponential cooldown: 30m → 60m → 120m → 240m
* No retries during cooldown
Despite this, even the one-page probe continues to return:
429 {"error":{"code":"too_many_requests","message":"too many requests"}}
The rate-limit streak has persisted overnight, while /account/limits and authenticated portfolio endpoints remain available.
Does /markets have a separate account-, route-, or IP-level throttle that is not reflected in /account/limits? Is there a longer recovery window after prior high-volume pagination, or anything else I should inspect?
I have also applied for Advanced API access, primarily for safer market discovery and batching.
Hi — I’m seeing a persistent 429 specifically on GET /trade-api/v2/markets.
My authenticated GET /account/limits currently reports:
* Tier: Basic
* Read bucket: 200 capacity / 200 refill rate
* Estimated /markets cost: 10 tokens
I initially had an overly deep paginated scanner, but I have since reduced it substantially and added defensive backoff:
* Normal scan: max 5 pages, 200 markets/page, ~50 estimated tokens
* Post-429 probe: exactly 1 page, ~10 estimated tokens
* Exponential cooldown: 30m → 60m → 120m → 240m
* No retries during cooldown
Despite this, even the one-page probe continues to return:
429 {"error":{"code":"too_many_requests","message":"too many requests"}}
The rate-limit streak has persisted overnight, while /account/limits and authenticated portfolio endpoints remain available.
Does /markets have a separate account-, route-, or IP-level throttle that is not reflected in /account/limits? Is there a longer recovery window after prior high-volume pagination, or anything else I should inspect?
I have also applied for Advanced API access, primarily for safer market discovery and batching.