Stop-limit entries after an exit on the path; exits for another entry survive a flat position

[alexgrover]

Controlled case 22 (stop-limit entries with exits), measured on TradingView (BINANCE:BTCUSDT 1h).

The bar rises through a short's stop-loss (64,614) and through a pending stop-limit long's stop (64,664). On TradingView:

1. the short's exit fills;
2. then the stop-limit long fills;
3. then the long's take-profit fills, on the same bar. That take-profit's strategy.exit was placed while the short was still open.

PineTS filled the long first, as a reversal that closed the short, and the take-profit only on the next bar.

Changes

• Stop-limit entries wait for an earlier exit on the path. Limit and stop entries already did (Broker emulator: FIFO exit pairing, immediate closes after an entry, exits before reversing entries on the bar path (#316) #423); stop-limit entries were left out. A deferred entry now also keeps the fill price computed for it. Otherwise the second pass would refill a stop-limit at the bar's open, because the first pass had already marked it triggered.
• When an exit leaves the position flat, only the exits for the closed trades are cancelled: those with no from_entry, or whose from_entry is one of the closed entries. An exit for another entry, placed while the position was open, stays. The rule exists to stop exits of a closed entry from attaching later with stale levels, and still does.

Tests

tests/namespaces/strategy/stop-limit-after-exit.test.ts: the short's stop, then the stop-limit long, then the long's take-profit, all on one bar. It fails on dev.

Results against TradingView (compared with dev)

• Controlled case 22: trade 27 → identical. No other controlled case changes.
• Probes (trailing, partial exits, calc_on_order_fills, sizing, opposite orders), public strategies, premium backtesters: no change.
• Unit suite: all committed tests pass. Oracle suite: 0 regressions.

Also checked: EURUSD 1h (5 controlled runs)

The five EURUSD runs all diverge on one signal: the 10- and 30-bar SMAs are mathematically equal on bar 496 (1.171326). TradingView's floating-point sums leave the fast one 2e-16 above, so it counts a crossover. PineTS rounds TA outputs to 10 decimals, so they're equal and the crossover comes one bar later. This is a numerical tie, not a broker difference, and isn't changed.

---

Note

Medium Risk
Changes core order-fill sequencing and exit cancellation in processStrategyOrders / processExitOrders; behavior is targeted at TV parity but affects edge cases with opposing entries and bracket survival across flat periods.

Overview
Aligns intrabar fill ordering with TradingView when a bar hits both an opposing exit and a pending stop-limit entry (controlled case 22).

Stop-limit entries now use the same defer-until-after-exits behavior as limit/stop reversals: if an exit leg is reached earlier on the bar path, the entry is deferred and its computed fill price is stored (_deferredFillPrice) so the second pass does not re-trigger at the open. Path-position logic for deferral also treats stop-limit like stop (not limit) for rising/falling along the path.

When a bar’s exits flatten the position, pending exit orders are cancelled only for the entries that actually closed on that bar (from_entry in the closed-trades set), not every exit that was placed while any position was open—so a long’s strategy.exit queued during an open short can still fill the long entered later on the same bar.

Adds stop-limit-after-exit.test.ts: short stop → stop-limit long → long take-profit on one bar.

^{Reviewed by Cursor Bugbot for commit 51e2bf9. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: 8c4a2926-9652-42ec-9f7c-d8b03d4a76af)