Calculating P&L When a Trade Spans Multiple Sessions

A long-running process in my system owns a unit of work and everything it creates is scoped to that process’s id. When the process rotates on a schedule and a late event arrives from an external system, the event gets filed under the new scope — leaving two records of one thing, exactly one of them resolved. The downstream FIFO matcher, correctly scoped to a single unit of work, then reads the orphaned half and invents a plausible entity to explain it. Nothing raises, nothing logs, and the derived ledger is never audited against anything. Post walks through why the obvious patch (widen the query by one scope) is an arbitrary bound dressed up as a fix, and what the actual boundary condition turns out to be.