Known issue in PineForge 1.9.1: with calc_on_order_fills, a same-ID market entry after strategy.close can be missed #723

Summary

In the case we measured, a strategy with calc_on_order_fills = true and pyramiding = 1 closes a position with strategy.close, and later, on one bar, issues strategy.entry with the same ID twice: first with a limit price that is never reached, then as a market order. On TradingView the strategy enters a new position (the limit order never fills). PineForge 1.9.1 does not enter, so the strategy has one trade fewer than on TradingView, with no diagnostic.

Measured scope

One script on BTCUSDT, a 60-minute chart, from 2024-01-01 00:00 UTC to 2024-03-01 00:00 UTC, compared with TradingView's exported list of trades:

Other order sequences, other pyramiding values and scripts without calc_on_order_fills have not been measured yet.

Affected versions

PineForge 1.9.1. The current development line behaves the same.

Effect

A trade that TradingView takes is missing from the PineForge result, so the trade list, the positions and every value derived from them differ from that point on.

Related

This is in the same order-handling area as #708, but a different symptom (#708: a second position opened past pyramiding = 1; here: a re-entry is missed).

Cause

With calc_on_order_fills = true and no open position, when one bar issues strategy.entry with an ID first with an unreached limit price and then as a market order, PineForge drops the later market order and keeps the earlier limit order pending. A test of both process_orders_on_close settings fails for exactly this reason on the current development line (one trade instead of two, no position afterwards, the limit order still pending) and passes with a first version of the fix; the control cases (the earlier position still open, a market order only, fill recalculation off, different IDs) are unchanged.

Workaround

No verified workaround yet.

Status

A fix is being finalized and checked. This issue will be updated when it is released.