Trying to understand why a lot of contract orders do not resolve to broker orders

[TobiasAntiGravity]

Hi

Looking at the order stack over the last couple of weeks I noticed that a lot of contract orders do not resolve to broker orders. This happened again yesterday;

I took a screen shot of the print out of interactive_order_stack yesterday at 17:41 GMT;

Taking a new screen shot today at 06:11 - none of the contract orders do not appear to have been resolved to broker orders:

In addition to the contract orders not resolving; the broker order stack remains the same even though my system was scheduled - and seemingly did a full daily update including the run_cleaner, in between the two screen shots;

I would have expected the broker order stack to have been changed after the daily update.

With regards to the contract orders not resolving to broker orders; the documentation section about broker order creation lists several conditions that the code checks before issuing an order, one of them being instrument lock. Is there any way to check the instrument lock to see if this is an issue?

I have done some checks with regrads to the mentioned conditions. In the case of CORN the system position limit is 1. I remember reading both in the book and in more detail on the blog about the problems with binary forecasts. Is this the issue? Is the position limit too small for the system to trade the instrument in a sensible manner?

Hope someone can shed some light on what is going on here - would be very much appreciated!

[robcarver17]

Best way to debug is to trade in 'manual mode'

So turn off the run_stack_handler (interactive_controls) and fire up interactive_order_stack. Delete all the order stacks (option 4/42). Then run update_strategy_orders in another window. You should then see a bunch of instrument_orders appear (option 0/1). Pick one (maybe from a market that is from the list above but also that is currently trading). Spawn a contract order (1/10). Then try and execute the order (1/12). The whole time you need to be copying and pasting all the diagnostic text. Hopefully it will become clear what the problem is. If not then post the trace here.

[TobiasAntiGravity]

Thank you so much for taking the time Mr. Carver!

I did the manual process - everything worked, which was as hoped as I had found the issue with the private_config.yaml.

How do I re-engage the stack_handler now; Do I have to clear out the order_stack before running, or will the stack handler just grab the stack and start working with it?

[TobiasAntiGravity]

I found out - started the stack handler - but it did not spawn any broker orders, so by process of elimination that leaves me with update_strategy_orders before starting stack handler.

Thanks again Mr. Carver - you're the Man as they say in the US!

[TobiasAntiGravity]

I have a lead - thought I would post here; looks like the above is strange behaviour, and that is stems from a incorrectly formatted private_config.yaml

I looked at the echos from the run_stack_handler and it looks like the remaining broker orders might be causing things to stop up; Both this night, and the night before the log is filled with the following output from start up at 00:15 to 04:55

where the output changes to Connectivity between IB and Trader workstation has been lost, and a subsequent Connectivity between IB and Trader Workstation has been restored - then - nothing. All output stops after this at 04:55:07.

Looking at the the gateway now - it says that two connections are active. This could be the run_capital_update process running, but according to htop run_stack_handler is still running. That is why I did not investigate further the previous days I got the critical error mail - it looked to me like things were running ok - and I thought the crash came at the stack handler was supposed to shut down.

That was wrong; Looking more closely now: The crash report for the 'run_stack_handler' came at 23:47:02 (GMT). This is not in line with process_configuration_stop_time which is set to 19:45. So obviously the stack handler was taking way too long to stop - and did not stop at all, it actually crashed.

I looked at the monitor.py output and found a stack trace

The stack trace ends at private_config.yaml

Looking at this file - I found the problem - a syntax error;

  bad_markets:
    - 'CLP'
    - 'BRENT'

should be;

  bad_markets:
    - CLP
    - BRENT

I used the same syntax as in ignore_instruments which does use single quotes.

Hopefully this is the reason for the problem

Will use the manual trade and try to get things going again as per Mr. Carver's reply above.