Limit exits fill only on trade-through; TradingView fills on exact touch (~1% of trades)

[dfl3xrs]

Summary

Comparing PineForge (release v0.1.19 / engine 0.12.3 / codegen 0.10.1, Docker pineforge-release:latest) trade-for-trade against TradingView Strategy Tester "List of Trades" exports for three futures strategies on ~1.07M 1-minute bars (COMEX micro gold, MGC), parity is 97-98% all-fields-equal. Excellent.

Of the remaining mismatches, every non-roll-day case has the same shape: a strategy.exit(limit=...) target that the bar's high (long) / low (short) reaches exactly to the tick is filled by TradingView and not by PineForge, which then exits later on the stop or the EOD flat. It looks like the limit-fill condition is strict (> / <) where TradingView behaves as >= / <=.

Setup

• syminfo.json: {"mintick": 0.1, "pointvalue": 10.0, "timezone": "America/New_York", "session": "1800-1700"}
• PINEFORGE_INPUT_TF=1, PINEFORGE_CHART_TZ=Europe/Stockholm, PINEFORGE_OVERRIDES={"initial_capital":"1000000"}, no magnifier
• Strategy shape: strategy.entry(..., stop=lvl) then strategy.exit(id, from_entry, stop=ep - r, limit=ep + r); calc_on_every_tick=false, pyramiding=0, process_orders_on_close default.

Four reproducible cases (MGC 1-min, bar timestamps UTC; the bar's extreme equals the limit price exactly)

strategy	limit	bar (open)	bar high/low	TradingView	PineForge
long	2684.90	2025-01-14 12:22	high 2684.9	filled 12:22 @ 2684.90	not filled; exited later @ 2676.70
long	3553.70	2025-09-02 07:44	high 3553.7	filled 07:44 @ 3553.70	not filled; exited 07:51 @ 3545.50
long	2047.60	2023-12-21 10:18	high 2047.6	filled 10:18 @ 2047.60	not filled; exited 10:29 @ 2045.80
short	2038.20	2024-02-27 20:29	low 2038.2	filled 20:29 @ 2038.20	not filled; EOD exit @ 2039.60

OHLC for the first case: 12:22 2683.9 / 2684.9 / 2683.7 / 2684.8. Entry prices and all other trades in these runs match TradingView to the tick, so this is not a data, timezone or contract-roll offset.

Expected: a limit exit fills when the bar's extreme equals the limit price (TradingView semantics).
Observed: the extreme must exceed the limit price.

Impact: ~1% of trades on these strategies, always in the conservative direction (a missed target becomes a later stop/EOD exit), so PF is slightly understated - e.g. 1.264 vs TV 1.282, 1.190 vs 1.201, 1.133 vs 1.155 across ~520-600 trades each.

Happy to share the three Pine sources, the OHLCV CSV and the TradingView exports privately if useful. Thanks for the engine - the parity is otherwise remarkable.

[luisleo526]

Thanks — four exact cases with OHLC and the "later exit at the stop/EOD" shape made this quick to pin down. The symptom is confirmed; the mechanism is slightly different from a strict >.

Reproduction. We replayed your first bar verbatim (mintick 0.1; 12:22 bar 2683.9 / 2684.9 / 2683.7 / 2684.8; long with strategy.exit(limit=2684.90)), plus the short mirror. A limit level that is exactly 2684.9 fills on that bar in v0.12.2 and main — the comparison is already inclusive. A level carrying a floating-point residue does miss: ep + (ep − lvl) gives 2684.9000000000005 for ep = 2683.8, lvl = 2682.7; the engine tested that raw level against the tick-quantized bar extreme, found no touch, and filled 3 bars later at the same price — your rows. Whether ep ± r picks up a residue depends on the operands, which is why it shows in ~1% of trades.

What TradingView does. Pinned with 40 sensor exports on NYSE:F, CME_MINI:ES1! and OANDA:EURUSD: TradingView stores a resting stop/limit level on the symbol's price grid whenever it lies within 0.01 / pricescale² of a grid price (for a 0.1-tick symbol that band is 1e-4, so any arithmetic residue is absorbed) and uses that grid price for the trigger and the fill.

Fix — merged. The order-level grid snap is on engine main (pineforge-engine #192, via the trade-for-trade parity gate), with a regression test built from your first and fourth cases. Your four rows should fill on the touch bar. A release is a separate step, so no date from me here. If you want to double-check on your side: print limit with str.tostring(limit, "#.################") on those bars — the residue should be visible; if the level is bit-exact and still misses, please send the sources privately as you offered, because that would be a different bug.

[luisleo526]

Closing as fixed on main (pineforge-engine #192); it will be in the next release. Please reopen if a bit-exact limit level still misses the touch bar on the released build.