-
Notifications
You must be signed in to change notification settings - Fork 20
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
mutating trade IDs? #12
Comments
Very thorough of you to notice. What happened is that the API had been returning rounded (to the "tens" place) trade IDs due to an unintended implicit cast in an SQL query in the back end. The bug in the back end has been fixed, but an unfortunate side effect is that trade IDs that were previously reported incorrectly are now being reported correctly, thus causing them to appear to have changed. You will notice that, in every case, the corrected trade ID, when rounded to the "tens" place, matches a previously reported, incorrect trade ID. You could use this fact to correlate the corrected records with your existing records. Apologies for the inconvenience. |
Incidentally, the "trade IDs" reported by the BIST API are really just the microsecond timestamps at which the trades occurred. |
Hey @whitslack - thanks for the quick reply! Understood. What what it's worth, in my experience it doesn't pay to model database IDs in software as numbers. Just because they look like numbers doesn't make them numeric. You can't add them or multiply them, one ID isn't greater than another. If you need to sort trades by time then it's best and clearest to use an explicit time field. But that's just my opinion! And the great thing about opinion is that it's easy to ignore ;) Using a timestamp to generate an ID leaves you open to have 2 identical IDs though. As unlikely as it is, it will happen at some point won't it? Or do you have a way to guard against that happening? I guess you can work out the exact likelihood from your data. What would go wrong if this did happen? Did you notify your customers of the change to the trade IDs? It's taken me a while to figure this out and it played havoc with my accounting, I probably won't be the only one. |
It won't be possible until computer hardware gets significantly faster. Back-to-back trades resulting from one limit order placement, despite being processed in native code in as tight a loop as we can manage, are still separated by hundreds of microseconds. No chance of duplicate trade timestamps for the foreseeable future.
I discovered the rounding issue on 14 July and immediately produced a fix, upon which I commented:
I followed up on 24 July:
The answer I received back was that the three biggest customers had reported that they would have no problems with the historical trade IDs changing and to go ahead with the fix. The fix was deployed to Coinfloor's internal test platform on 12 September and then to production on 20 September. Evidently no notification was ever sent out to customers. I do apologize for that. As you can see, I tried. |
Where were these announcement made, via email? I didn't get it. You say it won't be possible to get duplicate IDs - is that because you are processing trades on a single server? |
What I was trying to say is that I urged them to announce the change to customers by email, but I don't think they did it.
There are multiple servers that handle the APIs (WebSocket and BIST), but order matching (i.e., trading) occurs on a single server. |
I downloaded some transaction data via the coinfloor REST API a while ago and recorded it to disk. When I recently downloaded the same data I noticed that I had what appeared to be a bunch of over filled orders. On closer inspection I noticed that I have two almost identical trades for a single order, differing only by their id.
The trade as it looks today is this:
But in the past i had this:
(Identical values apart from the id)
But this older version of the trade (1501904560496850) is no longer returned but the API. It's as if the trade id isn't constant. Does it change? Could someone explain what's happened please?
The text was updated successfully, but these errors were encountered: