Known issue in PineForge Engine 1.9.1: stop-limit orders at some fractional limits #715

With process_orders_on_close=true, long stop-limit orders can remain unfilled when observed tick data reaches an executable fractional limit after activating the stop. This can omit a trade without reporting an error. A short stop-limit order at the measured limit fills on the expected bar, but at a price that differs from the expected one in the last binary digit (it prints as the same price at the tick's two decimals).

The following cases are confirmed in the released 1.9.1 engine and on main, using a price tick of 0.01:

Measured example: an order to buy 1 unit with stop 100.00 and limit 99.99, submitted at a bar's close with orders processed on close; the next bar's observed prints are 100.00, 100.00, 99.99, 99.99. The expected entry is 1 unit at 99.99 on that bar; 1.9.1 produces no entry.

The defect is confirmed with observed tick input. Bar-only input has not been checked.

Verified workaround: none known for the affected tick-input cases.

A fix ships in the next release (1.10.0).

Updated 2026-11-03: this issue first said "the next patch release". The next release is 1.10.0, a minor release.

Corrected 2026-11-02: short orders at that limit fill at a price that differs from the expected one in the last binary digit; long orders remain unfilled.

Correction 2026-11-03: the statement that the short order fills at a price differing "in the last binary digit" compared the engine with an exact-decimal value, not with a TradingView measurement. A TradingView export prints prices at the instrument's decimals and cannot show that difference. We withdraw that part of this issue, including the "price differs in the last binary digit" note in the table. The long orders that remain unfilled are unchanged and are being fixed.