I'd add a two-instance test to the pending-order check: both instances read an empty order list before either placement becomes visible. Each can pass the same guard and still send an order. A shared reservation needs a defined release path after acknowledgement, rejection or restart, so it doesn't quietly become a second permanent halt. Does the fix serialize entry decisions across instances on one account, or only count pending orders within each instance?
Good catch, and the race is real: two instances can each read an empty order list before either placement is visible, so a per-instance guard passes in both. As far as I can tell from the public PR, the fix limits resting orders per instance (one at a time, expiry-based cancel). I haven't seen anything that serializes entry decisions across instances on one account, and I haven't verified that by running it, so I won't claim it does. Your point about the release path matters too: a shared reservation needs an explicit release on ack, reject and restart, otherwise it becomes the same kind of permanent halt the post describes. For anyone running more than one instance on an account, the safer check is the broker-side order list at placement time, not a local counter.
A fresh broker query narrows the window, but two instances can still query before either submits. I'd add one more test: the broker acknowledges an order before that order appears in the next query. Releasing the reservation on acknowledgement would reopen the race. I'd keep it until the accepted order is reconciled, release it on an explicit rejection, and reconcile after a timeout or restart before allowing another placement. I haven't run that test on this PR.
Arnold Holm
I turn your trading setup into an MT5 bot with your prop firm's daily and max loss rules built in. Try it free on demo first.
I'd add a two-instance test to the pending-order check: both instances read an empty order list before either placement becomes visible. Each can pass the same guard and still send an order. A shared reservation needs a defined release path after acknowledgement, rejection or restart, so it doesn't quietly become a second permanent halt. Does the fix serialize entry decisions across instances on one account, or only count pending orders within each instance?