Search posts, tags, users, and pages
Most risk guards are one line long. "Don't open a trade if one is already open." "Stop trading if today's loss passes the limit." The line is usually correct. The bug is in what it looks at: a guard i
honest-backtest.hashnode.dev5 min readMarkdown supported · ⌘↵ to post
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.
Agreed, a fresh broker query only narrows the window, it doesn't close it. Releasing the reservation on acknowledgement reopens the race for exactly the reason you give: the ack can arrive before the order shows up in the next query. Holding it until the accepted order is reconciled, releasing on an explicit reject, and reconciling after a timeout or restart is the right shape. I haven't run that test either, so for this PR I can only say what the code does and doesn't cover, not that it survives it.
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?