-
Notifications
You must be signed in to change notification settings - Fork 500
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
Orders from getOrderbook are not always sorted correctly #766
Comments
See this: https://www.xrpchat.com/topic/8223-rippleapi-orderbooks-order-is-by-string-quality/ |
Would you like to contribute a PR? 🙂 |
Sure. How much are you paying ? |
I'm having the same issue, but only with asks
Gives the following list makerExchangeRates for asks:
It seems like its an ordering issue on the base API of Ripple and not just this library. It should be done on the main API to ensure the real-time data that we receive using this library. |
@antondalgren It's a problem of ripple-lib (RippleAPI), because the server returns the book in the correct quality order. |
@tuloski Then it should be an easy fix |
I have read the code review and the issue which stems from some unnecessary sorting. Personally ripple-lib looks like Homer Simpson's super car which immediately sent his brother into bankruptcy. This is the second time I see something like it (the first one being maxFee param that caused massive XRP bleed and had to be resolved by placing 2XRP hard cap). So I think ripple-lib should not be a front layer on the ledger's API. People should use their own websocket client to connect and communicate while ripple-lib should be turned into a set of helper tools (signing, interpreting low level json response, etc). |
@inmyth Good point. We should recommend using |
- Use formatBidsAndAsks with request instead of getOrderbook - Deprecate getOrderbook, which does not sort orders correctly - Resolve #766
I noticed that orders from the function
getOrderbook
return bids and asks sorted bymakerExchangeRate
from the lowest to the highest. But some of the orders are sometimes inserted at the wrong sequence, especially if the rate is 0.1. For example this is the order book from following configurationIn the result below, all orders whose rate is exactly 0.1 come first. The ones who rates are smaller (0.027) come later.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: