The Guard That Counts the Wrong Thing

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.