Conditional/stop orders invisible to getOrders — broker state blind spot

[atxinsky]

Summary

When using Binance Futures, conditional orders (stop-loss, take-profit) placed via the platform are not returned by getOrders (which maps to ccxt's fetchOpenOrders). This creates a critical blind spot where the system believes no stop-loss is in place when one actually exists.

Impact (observed in Demo)

1. False "naked position" alerts — Alice repeatedly warned about zero stop-loss protection (15+ times) when stops were actually active on Binance, causing unnecessary panic
2. Duplicate order placement — Since verification logic can't see existing conditional orders, it re-submits stops, resulting in 3x duplicate stop-losses and 3x duplicate limit orders that had to be manually cleaned up
3. Phantom order tracking — Brain state records orders it thinks it placed, but can't verify against broker reality, leading to hallucinated order IDs (e.g. cab7db76)

Root Cause

Binance separates:

• Regular orders → GET /fapi/v1/openOrders (what ccxt's fetchOpenOrders hits)
• Conditional orders (stop-market, take-profit-market) → GET /fapi/v1/openOrders with type=STOP_MARKET or via GET /fapi/v1/conditionalOrders

The current CcxtBroker implementation only calls the standard path and misses conditional/stop orders entirely.

Suggested Fix

In CcxtBroker.ts, the order query methods should:

1. Fetch both regular and conditional orders (ccxt's fetchOpenOrders with params: { type: 'STOP_MARKET' } or equivalent)
2. Merge results before returning to the caller
3. Consider a unified getAllActiveOrders() method that covers all order types

Environment

• OpenAlice v0.9.0-beta.7 → beta.8
• Broker: Binance Futures (USDT-M) via ccxt
• Demo trading on ETHUSDT

Related

This blind spot also contributes to the duplicate order problem — without visibility into existing conditional orders, there's no way to implement idempotency checks before placing new ones.

[luokerenx4]

Thanks for the detailed write-up — this is a great catch. We'll get both #90 and #91 fixed in the next few days. Appreciate the contribution!

[luokerenx4]

Investigated and pushed a fix to dev in two commits:

Root cause: CcxtBroker.getOrder() used fetchOpenOrder/fetchClosedOrder which only query regular order endpoints. Conditional orders (stop-loss, take-profit) live on separate exchange endpoints and require { stop: true } to be visible via CCXT. Same blind spot affected cancelOrder and modifyOrder.

Fix (73a9323, 85cc72e):

1. getOrder / cancelOrder / modifyOrder now fall back to { stop: true } when the regular endpoint can't find the order
2. Introduced an exchange override system — each tested exchange can have its own implementation for order queries, while untested exchanges use a sensible default. Currently Bybit has a verified override; Binance and others use the default fetchOrder + { stop: true } fallback path.

Verified on Bybit (demoTrading e2e): placed a stop-loss trigger order → getOrder found it → cancelOrder cancelled it ✓

Binance Futures (your case): the default path should work based on our CCXT source analysis — Binance's fetchOrder supports { stop: true } correctly. However, we don't currently have a Binance Futures testnet to verify end-to-end.

Could you test on your Binance Futures demo setup and let us know if conditional orders are now visible? Pull from dev branch. If anything still misbehaves, the error logs should point us to exactly which API call fails.