Problem
The replace message built in src/engine/hot_loop/order_builder.rs carries OutsideRTH unconditionally:
(6433, "1"), // OutsideRTH (preserve from original)
The comment says the value is preserved from the original order. It is a literal, and there is nothing to preserve it from: types::Order has no field for the flag, so whatever the order was submitted with is not tracked and cannot be restated.
The submit path is correct — it emits 6433 only when the caller asked for it, and omits the tag entirely otherwise. So the default order is regular-hours-only, and the first modify silently changes that.
Impact
Modifying an order's price or quantity turns on extended-hours eligibility regardless of how the order was placed. A resting stop submitted for regular hours only becomes eligible to trigger outside them as soon as it is touched.
Nothing surfaces the change. The gateway accepts the flag, the replace is acknowledged normally, and the order reads back as intended apart from the one field the caller never set. The failure shows up as a stop taken out by a thin pre- or post-session print at a level the regular session never traded.
Both entry points reach it: EClient::place_order on an already-tracked order id, and Context::modify.
Solution
Track the flag on the order and restate it on the replace:
- add the field to
types::Order, set from the submit request and from the recovery record on reconnect, where the server restates the order and the flag is available on the wire
- emit 6433 on the replace only when the order carries it, which is what the submit path does for the same order
Omitting the tag rather than sending 6433=0 keeps the two messages consistent, and leaves the server's own setting alone in the case where the original order is not tracked.
Problem
The replace message built in
src/engine/hot_loop/order_builder.rscarries OutsideRTH unconditionally:The comment says the value is preserved from the original order. It is a literal, and there is nothing to preserve it from:
types::Orderhas no field for the flag, so whatever the order was submitted with is not tracked and cannot be restated.The submit path is correct — it emits 6433 only when the caller asked for it, and omits the tag entirely otherwise. So the default order is regular-hours-only, and the first modify silently changes that.
Impact
Modifying an order's price or quantity turns on extended-hours eligibility regardless of how the order was placed. A resting stop submitted for regular hours only becomes eligible to trigger outside them as soon as it is touched.
Nothing surfaces the change. The gateway accepts the flag, the replace is acknowledged normally, and the order reads back as intended apart from the one field the caller never set. The failure shows up as a stop taken out by a thin pre- or post-session print at a level the regular session never traded.
Both entry points reach it:
EClient::place_orderon an already-tracked order id, andContext::modify.Solution
Track the flag on the order and restate it on the replace:
types::Order, set from the submit request and from the recovery record on reconnect, where the server restates the order and the flag is available on the wireOmitting the tag rather than sending
6433=0keeps the two messages consistent, and leaves the server's own setting alone in the case where the original order is not tracked.