-
Notifications
You must be signed in to change notification settings - Fork 732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get the HTTP response code for requests made? #382
Comments
+1. I'm running into this because I get the "slow rate limit exceeded" error, which makes no sense since I'm already doing the required rate-limiting. The only solution is to retry when Coinbase decides to randomly do this extra rate-limiting beyond what is specified in their docs. |
What specific kinds of requests are you making when getting throttled? If you are polling prices this is not good practice and will cause all sorts of problems with your trading strategy (due to the variable ping delay in responses). Since response codes are not revealed you simply use your own logic to decide what to do based on the contents of the message, and also in-case the response is blank. |
It gets worse. I emailed them about this back in early October and they responded: "We're not familiar with the slow rate limit message either, but very likely they are interchangeable. Can you please provide the full message?" So they are either incompetent or too lazy to look at their own code. Any information on this unspecified rate limit would be appreciated. |
no one has explained the kind of requests they are making when getting the error |
I got the error when retrieving historical data, but when I was
rate-limiting myself carefully to remain below the limit in the docs
(something like 3 or 4 requests per second, I don't recall.). In any case I
printed out time stamps and guaranteed that my requests were going in slow
enough, but I still got that error. And I was only using one process,
nothing else hitting it from my static IP, etc etc. Seems like a bug and
lack of documentation on Coinbase's side.
…On Fri, Nov 15, 2019 at 2:35 PM noah222 ***@***.***> wrote:
no one has explained the kind of requests they are making when getting the
error
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#382?email_source=notifications&email_token=AAIEQPWASSVIQK5V6LXEZBTQT4P3BA5CNFSM4JBDX5C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG5UCQ#issuecomment-554555914>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEQPTPDCXGX2MZ64JM6VDQT4P3BANCNFSM4JBDX5CQ>
.
|
yes, rate limiting on historical requests is not the same as the regular
api and they don't explain this anywhere. It's best to leave at least 1
second between requests in order to not get blocked. It used to just stop
responding, now I guess they at least give an error.
On Fri, Nov 15, 2019 at 5:46 PM Eric Nichols <[email protected]>
wrote:
… I got the error when retrieving historical data, but when I was
rate-limiting myself carefully to remain below the limit in the docs
(something like 3 or 4 requests per second, I don't recall.). In any case I
printed out time stamps and guaranteed that my requests were going in slow
enough, but I still got that error. And I was only using one process,
nothing else hitting it from my static IP, etc etc. Seems like a bug and
lack of documentation on Coinbase's side.
On Fri, Nov 15, 2019 at 2:35 PM noah222 ***@***.***> wrote:
> no one has explained the kind of requests they are making when getting
the
> error
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#382?email_source=notifications&email_token=AAIEQPWASSVIQK5V6LXEZBTQT4P3BA5CNFSM4JBDX5C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG5UCQ#issuecomment-554555914
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAIEQPTPDCXGX2MZ64JM6VDQT4P3BANCNFSM4JBDX5CQ
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#382?email_source=notifications&email_token=AJ6RVIKTX3MXWA5JZJ2KAG3QT4RGBA5CNFSM4JBDX5C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEG6KBQ#issuecomment-554558726>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ6RVIJSOANH622WPKZLB7DQT4RGBANCNFSM4JBDX5CQ>
.
|
Also retrieving historical data. I looked into it a bit further and the error is triggered after ~1,000 requests at an average request/second rate of about 1.5. Reducing this to about 1.3 requests/second avoids the error when making about 2,000 requests. So 1 request per second is probably a safe bet. |
cool, thanks for the info. don't forget when working with the historical
data to scan through it and fill in any missing data points. What I mean is
that if you are calculating averages with a moving window then they will
not be correct because if a trade did not happen in that interval, there is
no data presented for that candle in this API. network outages and errors
also cause some data to be missing. It's best to copy the last close price
into those candles to ensure proper averages
…On Fri, Nov 15, 2019 at 8:01 PM Bryan Failing ***@***.***> wrote:
Also retrieving historical data. I looked into it a bit further and the
error is triggered after ~1,000 requests at an average request/second rate
of about 1.5. Reducing this to about 1.3 requests/second avoids the error
when making about 2,000 requests. So 1 request per second is probably a
safe bet.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#382?email_source=notifications&email_token=AJ6RVIPK2XXGLAAI2DYENIDQT5A5HA5CNFSM4JBDX5C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHFCCI#issuecomment-554586377>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ6RVINPAOVV3MHIUJ7IERLQT5A5HANCNFSM4JBDX5CQ>
.
|
The response code is not currently exposed by the API, but there is an open PR that will implement this #260 |
Hey there!
I'm trying to add some retry / error handling logic to the code that I'm writing.
I want to be able to split between errors that should be retried and ones that should not. I feel a good split is 4xx as non-retriable and 5xx as retriable.
Any way I could get this status over? The error messages that are contained in the API response in case or error are 1. not documented all in one place (that I could find) 2. make it hard to split them between such error types.
Please let me know if you have any suggestions, thanks!
The text was updated successfully, but these errors were encountered: