Consecutive prior FAILED checks for this signal (0 = first check / healthy). Managed by the framework: a failed check increments the counter carried by the next ping while the failure is tolerated as transient (CC_ORDER_CHECK_RETRY_ATTEMPTS); a successful check resets it to 0.
true when called during a backtest run — adapter should skip exchange calls
Strategy/exchange/frame routing context
Market price at the moment of the ping
Maximum drawdown experienced during the life of this position up to this event
Peak profit achieved during the life of this position up to this event
Unrealized PnL of the open position at the moment of the ping
Position direction
Effective entry price (may differ from priceOpen after DCA averaging)
Effective stop-loss price at the moment of the ping
Effective take-profit price at the moment of the ping
Unique signal identifier (UUID v4) the order belongs to
Trading pair symbol, e.g. "BTCUSDT"
Total number of DCA entries (including initial open)
Total number of partial closes executed
Monitored state: "active" — open position order, "schedule" — resting entry order
Virtual time of the event: candle timestamp in backtest, wall-clock tick time in live
Payload for the order synchronization broker event.
Emitted automatically via syncPendingSubject on every live tick while a signal is monitored, BEFORE the framework evaluates completion. Forwarded to the registered IBroker adapter, routed by
typeto the matching callback:type: "active"— pending signal (open position), before TP/SL/time evaluation — delivered toonOrderActiveCheck;type: "schedule"— scheduled signal, before timeout/price-activation evaluation (the order in question is the resting entry order) — delivered toonOrderScheduleCheck.The adapter should query the exchange by
signalId. Returning normally keeps the signal under normal monitoring. Throw semantics (see IBrokerOrderVerdict):attemptincremented, up to CC_ORDER_CHECK_RETRY_ATTEMPTS consecutive failures before the framework acts terminally (a successful check resets the streak).NOTE for type "schedule": if the resting entry order actually FILLED, confirm the fill via
commitActivateScheduledinstead of throwing — a throw here is a terminal cancel, not an activation.