Consecutive-failure streak at the moment of this decision: 0 — the check confirmed the order (healthy), >0 — this many consecutive transient failures are currently tolerated (order assumed still open).
Always false: order checks are live-only (kept for cross-channel filter uniformity)
Market price at the moment of the check (VWAP)
Exchange name where signal was executed
Timeframe name (empty string in live mode)
Maximum drawdown experienced during the life of this position up to this event
Original entry price before any DCA averaging (initial priceOpen)
Original stop loss price before any trailing adjustments
Original take profit price before any trailing adjustments
Peak profit achieved during the life of this position up to this event
Position activation timestamp in milliseconds
Unrealized PNL of the position at the moment of this event
Trade direction: "long" (buy) or "short" (sell)
Effective entry price (may differ from priceOpen after DCA averaging)
Effective stop loss price (may differ from original after trailing)
Effective take profit price (may differ from original after trailing)
Signal creation timestamp in milliseconds
Complete public signal row at the moment of this event
Unique signal identifier (UUID v4)
Strategy name that generated this signal
Trading pair symbol (e.g., "BTCUSDT")
Timestamp from execution context (tick's when)
Total number of DCA entries (_entry.length). 1 = no averaging done.
Total number of partial closes executed (_partial.length). 0 = none.
Monitored state: "active" — open position order, "schedule" — resting entry order
Post-verdict order-check CONTINUE event.
The pre-verdict OrderCheckContract (syncPendingSubject) is the ping REQUEST — it fires before the broker adapter answers. This event is its resolved counterpart for the NON-terminal outcome: the framework decided the order is still open on the exchange and monitoring CONTINUES. Emitted on every live tick while the signal survives the check, discriminated by
type:type: "active"— the order backing an open position (pending signal);type: "schedule"— the resting entry order of a scheduled signal.attempttells which continue-path fired:Live-only: backtest never runs order checks. Notification-only channel: listener exceptions are swallowed at the emission site (logged + errorEmitter) and never affect the already-made monitoring decision.