Valerii Sakara

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.

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.