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
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
signalIdand THROW ONLY when the order is definitively NOT FOUND by that id (filled, cancelled, or liquidated externally). A throw propagates to CREATE_SYNC_PENDING_FN, which makes the framework close the pending signal with closeReason "closed" (type "active") or cancel the scheduled signal with reason "user" (type "schedule"). Returning normally keeps the signal under normal monitoring.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.CRITICAL: transient/network errors (timeout, 5xx, rate limit, disconnect) must be SWALLOWED — return normally instead of throwing. A thrown network error would wrongly close an open position. Only a confirmed "order not found by id" response is a valid reason to throw.