Trade.cancelAllOrders() bug?

[DTurcitu]

Hi, I'm using an exit strategy in my code, as well as a stop order for protection. Thus, upon reaching exit conditions of a trade, my code looks like this:

...
Trade.cancelAllOrders(getSymbol());
tempid=Trade.sellMarket(getSymbol(),nqty);
debugPrintln(getSymbol()+" position close via SELL MARKET order with OID "+tempid);
...


Now I've tested this with paper trading and it worked great, used it for several trades in Live Trading via an IB account and it also worked great. This is why I was surprised to notice today that the aforementioned code DID NOT CANCEL MY STOP ORDER even though it closed my position with the sellMarket order!

So basically the first line of code was ignored/did not execute and then the 2nd and 3rd did!

Do you have any idea why this could happen? I've checked my settings and they seem fine, and just yesterday the code worked correctly on the same symbols with the same IB account and settings. Normally I'd suspect a disconnect from the broker but would it even be possible for that to happen and for a reconnect to occur BEFORE the immediate next line of code was executed? It seems highly unlikely.

I'd appreciate any ideas as to the cause of this behavior.

Thank you

[AdamS01]

No this is not realy a bug
Orders are not executed sequentially
This is a truly event driven environment

Your cancel all order will read list of orders from broker
That takes time

Quite often it will find the following order and cancel it too

I never use cancel all erc
Except when I close the session
Yiu must keep track of your orders
And cancel hem individually

The problem is that before cancellation you need to check the order status
To confirm that order is still active
And only then you should request cancellation
But in the time between your check and
Before ib receives request for cancellation
Your order may be filled
And you may still receceove a an error message
And efs-at may be stopped with unrecoverable error

[DTurcitu]

Well thankfully I was already keeping track of orders so I just added individual Trade.cancelOrder() commands.

Frankly, I'd like to skip part of the order status checking, since as you said it may not work 100% of the time anyway due to delays. Therefore, my next question would be: assuming an order is cancelled or filled, would Trade.cancelOrder() of that particular order throw an error?

From what you're saying though, it seems human monitoring of the process is inevitable.

Another weird event I can't explain was that I had an order placed on Saturday 30-minute bar (I usually work on 10-30 minute bars) of a symbol that ONLY trades during weekdays on a given hourly schedule. And yet I came back from the weekend on a Monday to find that my Paper Trading simulation had placed an order during a bar on Saturday that shouldn't have existed (and it was in the middle of the day too, not something like 00:30). Any idea what chart settings screwup I may have made to cause that? Also, can I enforce a particular trading schedule from the script?

Thank you so much for your answers

[AdamS01]

checking order status in my opinion is critical, as CancelOrder() on cancelled or filled order will return error - order is in state which can not be modified;
and EFS will stop execution

regarding orders execution on Saturday - that depends on TWS /IB accepting orders


time selection

you can get the time of current bar using the following function:
nBarTime = getBarTime(0);

and compare that to your session starts time which can be obtained as follows

startTime = TimeToMinutes("10:00");
endTime = TimeToMinutes("16:00");

if ( startTime < nBarTime && nBarTime < EndTime )
... trading allowed
....

//== Converts string time representation to minutes
function TimeToMinutes( sStr ) {
var i;
var nTmp;

if ( sStr == "0" ) return( -1 );

i = sStr.split( ":" );
nTmp = 0 + (i[0] * 60) + (i[1]*1);
return ( nTmp );
}
//get the current bar time (as total minutes)
function getBarTime( nOffset ) {
var nTmp = 0;
nTmp = (getHour(-nOffset)*60) + getMinute(-nOffset);
return( nTmp );