Problem
OrderRequest::Modify carries a price and a quantity. It carries neither the time-in-force nor the order type, and the encoder re-asserts whatever the tracked original held.
So re-placing a tracked order id with a different TIF, or a different order type, is accepted and acknowledged — and neither change reaches the gateway.
Impact
A caller converting a DAY order to GTC through the documented modify path gets an order that still expires at the close. A caller changing a limit to a stop gets a limit. In both cases the modify is acked normally and nothing reports that the change was dropped.
This is the same shape as #247, which covered the outside-RTH flag, and as #334 for the fields that define an order type — the remaining fields on the same message.
The existing tests do not cover it
modify_tif_day_to_gtc_via_resubmit and modify_order_type_lmt_to_stp both assert only that a Modify request was emitted. Neither asserts the resulting TIF or order type, so both pass while the behaviour they are named for does not happen. They should assert the emitted wire values, and will fail until the request carries the fields.
Solution
Carry the time-in-force and the order type on the modify request, and emit them, rather than restating the tracked original.
Problem
OrderRequest::Modifycarries a price and a quantity. It carries neither the time-in-force nor the order type, and the encoder re-asserts whatever the tracked original held.So re-placing a tracked order id with a different TIF, or a different order type, is accepted and acknowledged — and neither change reaches the gateway.
Impact
A caller converting a DAY order to GTC through the documented modify path gets an order that still expires at the close. A caller changing a limit to a stop gets a limit. In both cases the modify is acked normally and nothing reports that the change was dropped.
This is the same shape as #247, which covered the outside-RTH flag, and as #334 for the fields that define an order type — the remaining fields on the same message.
The existing tests do not cover it
modify_tif_day_to_gtc_via_resubmitandmodify_order_type_lmt_to_stpboth assert only that aModifyrequest was emitted. Neither asserts the resulting TIF or order type, so both pass while the behaviour they are named for does not happen. They should assert the emitted wire values, and will fail until the request carries the fields.Solution
Carry the time-in-force and the order type on the modify request, and emit them, rather than restating the tracked original.