ccxt: Kucoin Too Many Requests
I used:
exchange = ccxt.kucoin({
'enableRateLimit': True,
...
On one line one core run of fetch_olhcv loop But still have:
ccxt.base.errors.RateLimitExceeded: kucoin GET https://openapi-v2.kucoin.com/api/v1/market/candles?symbol=ALGO-USDT&type=1hour&startAt=1633301197&endAt=1634741197 429 Too Many Requests {"code":"429000","msg":"Too Many Requests"}
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 34 (11 by maintainers)
Commits related to this issue
- kucoin rate limit #10273 — committed to ccxt/ccxt by kroitor 3 years ago
- async kucoin rate limit #10273 — committed to ccxt/ccxt by kroitor 3 years ago
- examples/js/kucoin-rate-limit #10273 — committed to ccxt/ccxt by kroitor 3 years ago
- examples/js/kucoin-rate-limit #10273 — committed to ccxt/ccxt by kroitor 3 years ago
Hi everyone!
This issue is on the exchange side. The problem is that they don’t document the actual rate limits on the ohlcv endpoint and many other endpoints and they don’t serve the usage stats, which makes it impossible to fix on the CCXT side.
The only meaningful workaround solution for now is to add the handling for RateLimitExceeded like shown in the following examples:
I contacted the API developers of KuCoin and they are aware of this issue. They will release a new high performance endpoint to solve this around next week. I assume CCXT needs to implement this new high performance endpoint then? I’m also a freqtrade user, and I see @xmatthias is active in here so I’ll just tag him so he knows this too 😃
Quoted from developer:
i guess they could also just pay the higher bill on cloudflare … 😆 but we’ll see what they’ll come up with …
freqtrade users are seeing this issue as well (https://github.com/freqtrade/freqtrade/issues/5700) - if you look through the messages there, you’ll see that several people contacted support about this issue - and got told to “retry immediately - it’s our fault - but only with 429000 errors”.
Now i have a problem with that statement personally, as i don’t see it as official (otherwise their docs would state the same) - but it doesn’t feel like it’s getting better, but worse at the moment.
a simple script to test/retry this is the following - left it running for 5-10 minutes and ran into it twice.
I think i can work around it by using the
exchange.last_json_responseobject to get the “real” code - but maybe this should not raise aRateLimitExceeded(even though the http status code says so) - but rather a different exception, clearly identifying it as “retry immediately” request.Please log your kucoin requests and you will find out that the rate limiting in ccxt works well.
This is cloudflare error on the part of kucoin, which has nothing to do with your own actual requests rate, rather with their overall system health. You should contact them to find out more.
@dawadam
I found the solution.
Outdated history for pair KONO/USDT. Last tick is 17 minutes oldis in reality a bad wording forthere have been no trades on this pair for 17 minI asked the people behind the freqtrade bot to change the wording because it is not logical what it means.
The bot is getting candle data and trading even when it spams what seems like a warning telling you it is missing data. But it is because there have been no trades, so there is no candle data to get from the API.
And I checked the chart manually and there had not been any trades in the time span the bot was warning about.
KuCoin got many pairs with no trades for up to 2+ hours we know now. Something I thought was impossible on the world’s 2’d biggest exchange.
@kroitor I think to address this specific issue, you did all (the posted examples) whatever was doable in current situation (until KuCoin releases updated engine, which will be a different PR). I think this issue can be closed for now?
This is how my error looks like:
2021-10-30 13:03:54,919 - freqtrade.exchange.common - WARNING - _async_get_candle_history() returned exception: "kucoin GET https://openapi-v2.kucoin.com/api/v1/market/candles?symbol=FKX-USDT&type=1hour&startAt=1633799034&endAt=1635599034 429 Too Many Requests {"code":"429000","msg":"Too Many Requests"}"I get it all the time with KuCoin, but not on Binance.
Rate limit 200.
I get this error both on my VM in Germany and my home pc in another EU country.
If I download candle data or just turn dry-run on with the freqtrade.io bot it is spammed until everything is downloaded after 1000 years.
I hope my input is useful.
You are welcome, I help if I can.
Limits I confirmed with their agents last week: orderbooks(lvl2, lvl3), the standard limit is 10req/3s their cloudflare limit: 4000/s for a specific endpoint for all users
I doubt there is going to be any change in kucoin’s rate limiting issues simply because of their own comments within regard to server support.
They’re on technical support department says that the only way to truly resolve the problem is for you to have more IP addresses that you can rotate between.
I personally use a sliding scale when I get the response to slow things down slightly based upon the number of responses. I have found that it’s not too much of an issue as long as you don’t get too aggressive with the exchange. You can easily use around 500 millisecond rate limits as a base value and then add upon that based upon the number of messages per second to get for rate limiting.
@kucoin can not become a Bill Gates, Unless you pay higher bills to get more gates.
@krychla1 thx for your feedback! I’ll try on my side to see if tweaking the rate limits helps… Sometimes, their own API docs may be wrong on the actual limits, or might have slightly outdated numbers. Will do my best to investigate it as soon as I can.
its hard to reproduce, it happens time to time, I suppose worldwide during higher traffic. You will not be able to cause it by high load just on your side, unless you have king limits (thousands/sec) or have the possibility to ddos the domain 😃 I noticed several mentions on reddits with a few similarities, also I face this issue several times/day. I even raised my limits at kucoin, it had no impact.
@mablue yes, that may be the case. I can’t reproduce it on my side, with and without proxies. Will try more.