Files
Hermes-Skills/okx-auto-position/references/v4.5.34-2026-07-08-execute-returns-success-no-fill.md
T

4.0 KiB

v4.5.34 (2026-07-08) advisor --execute 返回 success 但未真下单 (SSL 之外的第二类静默失败)

与 v4.5.27 SSL 静默失败的差异

维度 v4.5.27 SSL/Timeout v4.5.34 本次
advisor 异常 抛 traceback / ReadTimeout / SSLError 不抛错,stdout 是干净 JSON
advisor 返回 contracts 0 或 N/A 正常数值(本次是 1.45/0.51/3.5 张)
advisor 返回 auto_execute False / 缺字段 true
实际持仓变化 0 0
frozenBal 变化 0 0
agent 误判 "⚠️ advisor 错误" 消息 " 已推送 X 张"假阳性

触发币种 (2026-07-08 实测)

  1. SPCX-USDT-SWAP short 新开仓 → advisor 推 1.45 张,execute 返回完整 JSON,实际持仓 = 0
  2. SPCX-USDT-SWAP long 新开仓 → advisor 推 3.5 张,execute 返回完整 JSON,实际持仓 = 0
  3. MU-USDT-SWAP short 新开仓 → advisor 推 0.51 张 @10x,execute 返回完整 JSON,实际持仓 = 0 (后续同币种加仓信号成功了 0.52 张)

共同特征

  1. 都是新币种合约(SPCX / MU 上线时间短)
  2. 都是首次/早期 execute(OKX 合约 metadata 未完全加载)
  3. advisor auto_execute: true,输出 JSON 含 tp_price/sl_price/contracts/margin 等所有字段
  4. 实际调单路径静默丢失(可能 OKX 内部订单路由 / 撮合层 reject,但无异常抛回 ccxt)

二次校验硬约束 (强制)

process_signal.py 的 execute 路径,绝对不能信 advisor --execute 返回的 JSON 字段。必须反查:

def verify_executed(symbol, expected_side, expected_sz_min):
    """调单后反查持仓 + 余额变化"""
    time.sleep(2)
    actual_pos = fetch_position(symbol)
    if actual_pos is None or abs(actual_pos) < expected_sz_min:
        return False  # 没真下单
    return True

反查不通过 → 推 "⚠️ {symbol} advisor 返回 success 但持仓未变化,需手动 retry" 到 QQ,不推"已跟单 X 张"。

v4.5.27 的修复不覆盖这种情况

v4.5.27 只处理 SSL/Timeout/ReadTimeout 异常路径,加 retry。但 v4.5.34 是 execute() 返回成功但不 fill,retcetry 没意义(再跑一次同样的 ccxt 路径还是同样结果)。

需要的是执行后反查持仓,不是执行前 retry

用户建议的修复方向 (未落地)

实测后,用户已多次确认:

  • 遇到 advisor 报 SSL/Timeout → 等 30-60 秒 → retry 一次 (v4.5.27)
  • 遇到 advisor 报 success 但 execute 未 fill → 必须反查持仓验证,反查失败推"⚠️ 需手动"
  • 反查通过 → 推" 已跟单 X 张"(才允许)
  • 这是 v4.5.18 post-execute-verification 的强化版

实战 case-by-case 决策树

advisor --execute 返回:
├─ 抛 traceback (SSL/Timeout/ReadTimeout)
│  └─ retry 一次 (v4.5.27)
│     ├─ 成功 → 推"已跟单"
│     └─ 仍失败 → 推"⚠️ advisor 错误,需手动"
│
├─ 返回 JSON 且 contracts > 0
│  └─ 2 秒后反查 /api/v5/account/positions
│     ├─ 该币种 pos 出现 + frozenBal 增加 → 推"✅ 已跟单 X 张"
│     └─ 该币种 pos 未出现 + frozenBal 未增加 → 推"⚠️ advisor success 但未 fill"
│
└─ 返回 JSON 且 contracts = 0 (余额不足)
   └─ 推"⚠️ 余额不足,建议仓位=0张"

关键陷阱

  1. 不要把 advisor 的 JSON 输出当 fill 凭证 — 它只是"已发出下单请求"的凭证
  2. 不要用 advisor 输出的 order_id — advisor 在 JSON 里没返回 order_id (v4.5.0 的 bug)
  3. 不要忽视"返回 success 但没 fill" — 这是 2026-07-08 SPCX 4 次都中招的根因
  4. 小额(< 0.5 张) / 新币种 是高发场景,要重点反查

关联

  • v4.5.0 假阳性成功 → v4.5.18 post-execute-verification → v4.5.27 SSL silent execute → v4.5.34 execute-returns-success-no-fill
  • 累计 4 个版本的 execute 失败模式,每个修复都覆盖了上一版的盲区,但不替代上一版
  • 终极统一修复:execute始终反查持仓,不依赖 advisor 返回值判断成功