Hi,
When deleting an order, normally it's deleted quickly. However I met a situation where I sent the deletion signal, and the order was not really deleted. On the next tick, my code still finds the order by ibgCreateOrderSnapshot. (Finally, the order got deleted in around 20 seconds)
My own position management logic has sth to do with the existing order (sth like: if the tp/sl order exists, then close the position and delete the associated tp/sl orders), hence the system tried to close the position (by making a reversed market order) the 2nd time, which resulted in an open position of the opposite direction without any protection. I would have taken a significant loss if the price went against me.
My question is: is there some way in your best practice to guarantee the deletion of the order, or to let me know the order deletion is either in progress or failed so I can handle my position management properly?
Thanks in advance.
How to guarantee the success of order deletion
-
- Site Admin
- Posts: 244
- Joined: Mon Apr 24, 2017 3:24 pm
Re: How to guarantee the success of order deletion
Function
returns the last order status reported back from IB Server.
"However I met a situation where I sent the deletion signal, and the order was not really deleted"
This should not happen at all.
Function
should always work 100 %, presumed you passed correct parameters and you are connected and the order was valid (so had a pending status).
But even, if not connected on call, once reconnected, the deletion should be done.
"When deleting an order, normally it's deleted quickly. However I met a situation where I sent the deletion signal, and the order was not really deleted. On the next tick, my code still finds the order by ibgCreateOrderSnapshot. (Finally, the order got deleted in around 20 seconds)"
There is always a little probability, you find an order in pending snapshot even it is actually deleted, perhaps, you did the snaphost when deleted
status not yet been reported back from IB server. In that case: so what ?
When it takes 20 seconds, please figure out who caused the delay. It should not be the plugin. It is a matter of some milliseconds
for deletion command on the way to IB server.
Code: Select all
ibgORDER_STATUS(int64 uid)
"However I met a situation where I sent the deletion signal, and the order was not really deleted"
This should not happen at all.
Function
Code: Select all
ibgORDER_DELETE (int connection_id, int64 uid)
But even, if not connected on call, once reconnected, the deletion should be done.
"When deleting an order, normally it's deleted quickly. However I met a situation where I sent the deletion signal, and the order was not really deleted. On the next tick, my code still finds the order by ibgCreateOrderSnapshot. (Finally, the order got deleted in around 20 seconds)"
There is always a little probability, you find an order in pending snapshot even it is actually deleted, perhaps, you did the snaphost when deleted
status not yet been reported back from IB server. In that case: so what ?
When it takes 20 seconds, please figure out who caused the delay. It should not be the plugin. It is a matter of some milliseconds
for deletion command on the way to IB server.