I have a question regarding "Margin" order statuses here.
What if your logic results in an order placement when there isn't enough cash? I have this when I run similar logic across many more stocks.

The bracket causes the creation of the stop-loss and take-profit, even though the original 'main' order could not execute... so eventually you end up in short positions when the bracket orders execute at their stop/limit prices. How should this be managed?

I tried doing order.cancels when a order.Margin status occurs, however sometimes the stoploss/takeprofit executes that day of creation, and the cancellation doesnt occur in time.

The bracket causes the creation of the stop-loss and take-profit, even though the original 'main' order could not execute... so eventually you end up in short positions when the bracket orders execute at their stop/limit prices. How should this be managed?

The stop-loss and take-profit orders are created but

Are canceled if the parent order cannot be accepted or is canceled

Are created inactive and will only become active (available for execution) if the parent is Completed

This is actually acts as a safeguard which prevents the execution of stop-loss or take-profitsell orders even if they are accidentally accepted.

If any of those 2 things is not working as described there for the implemented bracket order functionality, it would be a bug.

If the orders are issued manually with no relationship (parent/children or through the buy_bracket / sell_bracket), there is no way to avoid execution of one order, because the other was canceled.

@backtrader, exactly per my script provided in this post: "How is Getvalue() Calculated?".

I added a print when position goes negative as you suggested,and it only occurs after a bracket was submitted, the 'buy' goes to margin and then the stop-loss and take-profit subsequently (undesirably) execute.

Alternatively, you may get the same functionality when you run this multi example with higher stakes (such that many executions will result in a margin) or with many more stocks.

The script cannot know that the data will be fed in the wrong order. And the script (or the underlying platform for the sake of it) won't also fight it, because it makes not sense, to start with, to feed data in the wrong order. This is python and being it a dynamic language, with duck typing and a higher level of introspection something is always true: if you want to break it, you will break it.

In any case the start of the output generated by the test run in the blog post:

Your expectation may be that the platform fixes everything and then finds out that the data is in the wrong order. The platform could buffer the entire data stream, examine it, come to the conclusion that the order is wrong and then sort it. This would have several consequences:

Streams may originate for non-fixed length sources which may deliver in steps and it is not known it the stream will have an end (in practical terms it will always have an end)

Some people would complain about the extra time taken to do the check

Memory consumption would increase

For streams originating from Yahoo which have not been reversed by the user, one can always apply the reverse parameter. Described in Docs - Data Feeds Reference. Set it to True.

To simplify things, backtrader includes a yahoodownload.py tool which automatically does the job. The usage

@backtrader, it may be more productive to work off the code I have written.
You have seen this code before, but I have adapted it to your latest 'multi example' order management logic (full code & log copied at end)

I now get errors when the margin order status occurs, I get the following error once the main order goes to margin:

This is how I have interpreted the sequence of events, please feel free to correct me:

Bracket order created

Main, stop and limit order Submitted and then Accepted

Main order 'Margin' because not enough cash

doreders[0] set to None (because Margin is not alive)

Stop-loss tries to execute (see log where the order type SELL is printed immediately before the error)

At this stage the stock holding would go short, however the order maangement logic then errors when trying to index(dorders).
It appears to fall over when the index is matching the order.ref against the None object at the start of the dorders list (error log also shows this).

If I can be of further assistance to resolve this issue I would be happy to help. I love your platform and I want to see this functionality running!

My humble apologies for how this issue has been approached.
If I ever have a bug report in the future I will be sure to include that information.

As it turns out, you are quite right... I stuffed up on the version front and wasn't using the lastest. I have since upgraded and the script runs completely! Wish I knew this yesterday before wasting several hours trying to debug a problem which didnt exist (my mistake!)!!

I assure you I haven't abandoned the getvalue thread, I am still working on addressing your suggested solutions and will get back to you to confirm if I have resolved the issue regarding short positions as soon as I have time to do some more thorough testing.

As a suggestion, with those example codes, would it be possible to include all elements for users such as myself to do a full run without edits? Perhaps inclusion of the necessary files etc too would be valuable and save some time. I spent some time yesterday to try and get your blog post to run and didn't consider that I would have to incorporate additional code to re-order data etc. I understand that it would never have worked for me though given my version issues..! But this may be useful for others going forward.

Thank you for your time and patience in assisting me as I learn this platform and process.