-
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
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
fetchOrder (bitstamp) not working anymore -> "invalid nonce" #1902
Comments
|
@stabilus can you please show a minimal (shortest possible, but complete) snippet of your code to reproduce the problem? |
This will create the error:
|
Ok, can you please add verbose mode and paste the full verbose output (without the key) ? # ...
exchange.verbose = True # add this before the last line
print(exchange.fetchOrder(orderID)) Standing by for more info from you. Thx! |
This is the verbose output, followed by the error messages: 960016270 During handling of the above exception, another exception occurred: Traceback (most recent call last): |
Hi Kroitor |
Was about to post the same. Two problems: fetchOrder on bitstamp is 2 calls: first we check the orderstatus (open or closed), and then poll the according endpoint, depending on order status. (or so it should be, right now we check status and then we poll the "open" endpoint anyway, but that's an easy fix) Anyhow, first call goes perfectly, second call gives a nonce error. In the verbose output, we can see the nonce is reused, I believe this causes the problem.
|
This is the main problem, we should remove the second call from there. However, in your particular case, a workaround would be to enable rate limiting (set 'enableRateLimit': true on your instance). |
We're going to remove the |
nevermind this:
All the info for closed orders is in the "status" call. |
There's no fetchOrder for bitstamp anymore, there's just the fetchOpenOrders now. We will add emulation for the fetchOrder shortly.
|
so far, fetching openorders and closed orders had not been implemented in ccxt. If you implement that, that would already be a great feature to work with |
According to bitstamps API openorders are cached for 10 seconds while there is no cache for order status. In order to react quickly to order status changes, it might be advisable to continue using order status calls when implementing the fetchOrder method on the ccxt side. |
If it requires two calls, this is highly discouraged. Instead we propose to use the existing fetchOrderStatus with fetchOpenOrders and leave the order of sequential calls up to the user (won't decide on the order of sequential calls in the library). |
orderStatus output for a closed order:
for Open order: Could we make fetchOrder just this single call? |
Perfect! This is all we need! I would like to contribute to your great effort. Please state your BTC address for a small donation! |
Not affiliated, just a happy "customer" like you. |
404... ? |
Yes, we will reimplement it using the orders cache. For now we offer fetchOrderStatus + fetchOpenOrders (which is effectively the same as the former fetchOrder implementation).
We are not deleting it forever, just making calls explicit, and we're going to add a caching layer to bitstamp shortly as well. |
https://github.com/ccxt/ccxt#crypto ) Thx )
|
sent it to the opencollective by BTC. Thank YOU! |
Respectfully, it is not. I need details on closed orders, and the info is readily available in the same call used for fetchOrderStatus. Raw output:
I can make a fetchOrder() out of this call (single call now, not double as it was), the only drawback being that the info for open orders will be very limited. When we have a caching implementation, we can ofcourse use that instead. |
Thx! However, opencollective does not accept BTC %)) They accept fiat payments... if you want to contribute with crypto, your contributions are welcome, and the crypto addresses are:
Thx again) |
@wannesdemaeght I've restored the following for fetchOrder (for now): async fetchOrder (id, symbol = undefined, params = {}) {
await this.loadMarkets ();
let market = undefined;
if (typeof symbol !== 'undefined')
market = this.market (symbol);
let response = await this.privatePostOrderStatus ({ 'id': id });
return this.parseOrder (response, market);
} This looks like what you need, right? ) |
sorry, I'm limping behind... Traceback (most recent call last): |
I'm on 1.10.1113. |
@stabilus ok, one more fix is coming up... hold on |
Great, thanks.
This has to do with encoding and decoding the datetimestring.
any idea regarding the timestamp? raw format is this:
regarding parsing, I don't know what would be better: Please let me know how you want me to proceed. |
It's easily explained: no timestamp data for the order... The timestamp you're posting is the trade timestamp (gets parsed correctly). Nothing to do with encoding at all. The data is just missing for the order in this particular reply. Will fix for that as well.
No worries for now, I'm fixing the parser to output the trade amounts + order filled value at the very least. |
Right, makes sense. Anyhow, timestamp is not important for me :-)
Ideally we should return the following info: that info should be readily available from orderstatus. |
Not really, it isn't... the total amount of the order is still unknown.
We can only return that info for trades inside the order, but not for the order itself. For the order itself we can only return the filled amount, but not the total amount. |
if result == finished, amount total = amount filled ( in this case 2.50625000 LTC) |
@wannesdemaeght right, but only if it is finished (it can be partially filled) |
correct, but when it's not finished, it will come back as this:
so doesn't really matter if status == finished --> amount = sum of all transaction.amount (sucks that they put the amount as ltc / eth / ...) |
This isn't always the case. In case of a partial fill it will return status = 'Open' with non-empty transactions (not sure about that, tho, they may be caching it up to the moment when the order gets 'Finished'). And in that situation we can't deduce the total amount of the order from trades, unfortunately. Their API is too poor. |
the sum of amounts in transactions corresponds to the filled portion of an open partially executed order. so, perhaps the attribute "filled" could be provided in case of a partially filled order |
@stabilus yep, this is what I'm saying, we can provide |
Will upload a fix and will update you here soon. |
makes sense. |
@kroitor opencollective seems to have accepted BTC (they have a payment gateway for BTC). Next time I'll know your direct BTC address. :) |
@stabilus wow, didn't know that %) Thx again ) |
Ok, this is fixed in ccxt 1.10.1114 and fetchOrder should work normally now, as described above with respect to @stabilus , @wannesdemaeght let me know if you still have any difficulties with it. Thank you for your involvement! |
price: if status == closed --> (price per trade * amount per trade) / total amount |
@wannesdemaeght yep, you're right, will add that as well. |
I really love telling people what to do 🤣 |
works like a charm mate! For my understanding: fetchOrder makes 1 call to the exchange - not 2, correct? And it calls the bitstamp orderStatus method (which does not cache for 10 seconds). Correct? |
Exactly. |
great, and what about " it calls the bitstamp orderStatus method (which does not cache for 10 seconds). Correct?" |
Yes. |
Added price, cost and fee to fetchOrder return in ccxt 1.10.1115 |
Thanks man! Works perfectly. |
Method used to work, now it does not.
"raise ExchangeError(self.id + ' ' + self.json(response))
ccxt.base.errors.ExchangeError: bitstamp {"status":"error","reason":"Invalid nonce","code":"API0004"}"
I issued a brand new API key from bitstamp -> same problem. All other private API Key methods still work (I can place order, etc. but to fetch the order based on orderID creates the error.
Any idea why?
Thanks
Urs
The text was updated successfully, but these errors were encountered: