Function rejected_order_does_not_block_the_instrument 

pub async fn rejected_order_does_not_block_the_instrument<U: OrderExecutor + ?Sized>(
    ud: &U,
    id: &InstrumentId,
    ok_price: Price,
)

An order the broker refuses must not block the instrument: the next order on the same instrument goes through.

This guards a bug BCS once had: a failed place left the per-instrument queue busy, and every later order got “command queued” until restart. Two rounds:

1. One after another: a limit order at REJECT_PRICE must fail with an error other than [brokapi_core::Error::Unknown] (a refusal is a clear answer, not a lost one). Then an order at ok_price must succeed and is cancelled.
2. At the same time (tokio::join!): the refused order and the good order are in flight together. The refused one must fail, the good one must succeed and is cancelled.

Every place waits at most EVENT_TIMEOUT, so a stuck queue fails the scenario instead of hanging. A local rate-limit refusal (nothing was sent) is waited out and the order is retried under a fresh cid, up to 20 times. A cid is never sent twice, because a repeated place could create a second order.

ok_price is a far-from-market price the mock accepts. The mock must refuse REJECT_PRICE with a definite refusal. The command gate must be open, so call reconcile first.

Panics

With [conformance:rejected_order_does_not_block_the_instrument] <reason> when the refused order is accepted, is reported as Unknown, when a later order fails or hangs, or when a cancel fails.

Examples

brokapi_conformance::reconcile(&ud).await;
brokapi_conformance::rejected_order_does_not_block_the_instrument(&ud, &sber, Price::from(1)).await;