Skip to main content

query_main_link_contract

futu_backend::main_link_contract

Function query_main_link_contract 

Source 
pub async fn query_main_link_contract(
    backend: Arc<BackendConn>,
    origin_stock_id: u64,
) -> Result<MainLinkContractInfo>
Expand description

v1.4.106 codex F5: 发 CMD 6747 拉指定 future_origin_id 的主力合约真实信息.

入参: origin_stock_id 是主连合约 row 的 origin_id 字段 (Ndt_Qot_SecInfo::nFutureOriginID), 必须 > 0. 0 表示不是主连合约 — caller 应该在调本 fn 前用 info.future_origin_id != 0 提前过滤.

响应解析 (StockQueryRsp.arry_items):

  1. 找 stock_id == 入参 origin_stock_id 的 row。
  2. 读该 row 的 zhuli_id; C++ OnReply_MainLinkContract 把它放进 OMEvent p2 并只用作失败判断 (p2 == 0 => UnknownStock)。
  3. 如果 zhuli_id == 0, 表示 backend 没识别该 stock_id 是主力链路, 返 Err(FutuError::Codec("...")) —— caller 应该 fallback 用原 symbol 下单 (loud failure, 不 silent).
  4. C++ 随后把同一 row 的 stock_id 放进 OMEvent p3, 并在 APIServer_Trd_PlaceOrder.cpp:815-817 用 GetAPIStock(p3) 反查 code。 因此 Rust 的 real_stock_id 必须取 row.stock_id, 不是 zhuli_id。

超时: 走 BackendConn::request 默认 10s timeout. 如果 backend 慢或 不响应, PlaceOrder 整个流程会挂 10s 然后失败 —— 这是故意选择: 与 C++ 行为一致 (C++ 用 OMEvent push 模型, request 在 backend 反正会响应; Rust sync await 简化但保留同样语义).

错误: 任何 backend 错误 / decode 失败 / future_origin_id 不是主力链路 → Err(...). caller (PlaceOrder handler) 必须 propagate 让用户看到 loud error, 不 silent 用原 symbol (违反主连合约判定就是 silent-success 反模式, CLAUDE.md 坑 #45).