---
title: "Comment by Arnold Holm on \"The Guard That Counts the Wrong Thing\" | Hashnode"
description: "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"
url: "https://hashnode.com/posts/the-guard-that-counts-the-wrong-thing/6ab8223043a2c5b8de6937e6/comment/6ad7d2421712c35a5ccf673a"
---

[Discussion](https://hashnode.com/posts/the-guard-that-counts-the-wrong-thing/6ab8223043a2c5b8de6937e6)

Comment [The Guard That Counts the Wrong Thing](https://hashnode.com/posts/the-guard-that-counts-the-wrong-thing/6ab8223043a2c5b8de6937e6)

[Arnold Holm](https://hashnode.com/@stratcorealpha)

[Oct 20](https://hashnode.com/posts/the-guard-that-counts-the-wrong-thing/6ab8223043a2c5b8de6937e6/comment/6ad7d2421712c35a5ccf673a)

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?

[Valerii Sakara](https://hashnode.com/@arakas4488cmd)

[Oct 22](https://hashnode.com/posts/the-guard-that-counts-the-wrong-thing/6ab8223043a2c5b8de6937e6/comment/6ad7d2421712c35a5ccf673a#reply-6ada36f4069dbe4c2f4c3365)

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.

[Arnold Holm](https://hashnode.com/@stratcorealpha)

[Oct 22](https://hashnode.com/posts/the-guard-that-counts-the-wrong-thing/6ab8223043a2c5b8de6937e6/comment/6ad7d2421712c35a5ccf673a#reply-6ada3c086743863fd86712dd)

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.

[Valerii Sakara](https://hashnode.com/@arakas4488cmd)

[Oct 25](https://hashnode.com/posts/the-guard-that-counts-the-wrong-thing/6ab8223043a2c5b8de6937e6/comment/6ad7d2421712c35a5ccf673a#reply-6addf5f55819f19be2dd6c3e)

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.