Open juanigsrz opened 3 years ago
martianatwork
commented
3 years ago This is not a design flaw. The market maker should listen for websocket events and then cancel the order from its memory.
When exchange replies 201 for orders api it means instruction received not executed.
juanigsrz
commented
3 years ago This is not a design flaw. The market maker should listen for websocket events and then cancel the order from its memory.
When exchange replies 201 for orders api it means instruction received not executed.
I understand that you may do a workaround by listening to the websocket, but note that the cancellation event has been lost and thus the order status will not be updated to cancel. You can only know about this situation and how to create a hacky workaround by understanding the underlying exchange implementation.
Second consideration, what exchange (or just any popular service in general) in the world asks you to implement a client for a RESTful API along with a websocket client to check if your request has actually been processed successfully?
martianatwork
commented
3 years ago I understand what you mean but don't expect any changes.
You should implement your own matching engine and use 2.6.
Crypto.com is the exchange that does this or at least it used to do this.
To cancel the order immediately you have to be using in memory trading engine to be effective.
We have developed our own implementation of this if you are interested. Note: I'm not related to openware.
The
matchingqueue is configured with the settingclean_start: true. I assume this is because when initializingmatchingwe load allwaitorders and try to match them, and we do not have a straightforward way to know if a submit event in the queue corresponds to an already-loaded order or not, which might trigger processing an order twice.Consider the following case:
matchingcrashes, starts restartingmatchingfinishes restarting, purging its queue, deleting all cancel events