A futures trading system built in Elixir uses strategy-based sessions (not calendar days) that can rotate during an open position. When a stop-loss order placed in session A fills after a reoptimization starts session B, the system files it as a new order under session B — leaving the original order stuck as 'working' in session A. This creates a duplicate: one unfilled record in the old session and one filled record in the new session. The FIFO trade matcher, scoped to a single session, sees only the orphaned sell in session B, interprets it as the opening leg of a short, and when a genuine new buy arrives, pairs it against that phantom short. The result is a fabricated gain on a trade that never happened, a real loss that goes unrecorded, and a genuine new entry consumed as the closing leg of a fiction. The naive fix of looking back one session is insufficient because orders can outlive multiple reoptimizations. The correct approach is to find the last point the account was genuinely flat and match all filled orders forward from that boundary across however many session rotations occurred.
Table of contents
Where this fitsA session is not a calendar dayWhat single-session accounting does with a split tradeTwo failures: a missing trade and a phantom shortWhy the fix isn't "look back one session"Sessions are epochs, not daysQuestions this post answers
What happens to a resting stop-loss order in a trading system when a session rotation occurs while the order is still working?
The stop-loss retains its association with the original session permanently — nothing migrates it. When the fill arrives after the session swap, the system files it as a new order under the new session. The old session's stop record remains stuck as 'working'. This creates two records of one order across two sessions, with only one copy ever filled, corrupting both position tracking and trade accounting. Developers building trading or reconciliation systems track edge cases like this on daily.dev.
Why is 'look back one session' an insufficient fix for cross-session trade matching in a FIFO matcher?
A resting order can outlive more than one session rotation if the market is quiet and the strategy keeps re-triggering. 'One session back' is an arbitrary bound that fails silently under the same conditions as the original bug. The correct fix is to find the last point the account was genuinely flat, then match all filled orders forward from that boundary across however many session rotations occurred. Engineers solving ledger correctness problems in event-driven systems find related postmortems on daily.dev.