[bitmex_websocket] websocketでorder(注文情報)を取得しようとしてハマるの回

2019年5月7日 22:02

以前のnoteで「[bitmex_websocket] websocketでticker,orderbook,trade情報を取得しようとしてハマるの回」を書いたのですが、今回はorder(注文情報)を取得しようとしてハマったお話です。

メッセージ、アクションの種類

今回使用したbitmex_websocketで取得できるメッセージは、

・quote
・trade
・execution
・margin
・position
・instrument
・order
・orderBookL2

の８個です。

websocketで通知される個々のメッセージに対するアクションは

・partial　（初回データとデータ構造等の情報）
・insert　（挿入）
・update　（更新）
・delete　（削除）

の4つがあるのですが、orderbook, position, margin, instrumentなどの全部のメッセージで上記の4つすべてのアクションが通知される訳では無いようです。

私が調べたところでは以下のようでした。

次の３つは、partial, insertのみ通知される。
　- quote
　- trade
　- execution
配列に追加されていくタイプの情報ですね。

次の３つは、partial, updateのみが通知される。
　- margin
　- position
　- instrument
一つのデータを更新していくタイプの情報ですね。

次は、partial, insert, updateのみが通知される
　- order　←　今回ハマった注文情報

次は、partial, insert, update, deleteのすべてが通知される
　- orderBookL2

今回ハマったのは「order(注文情報)」です。

ご存知のように注文には発行、約定、キャンセルなどの操作があり、当然キャンセルした注文は注文リストから削除されるはずです。

ですが、注文情報メッセージには「delete」アクションが通知されません。

その代わりと言ってはなんですが「update」時のメッセージ内容に次のデータが含まれていた場合

leavesQty = 0

注文が削除されたこととするらしいのです。
（元祖bitme_websocketの作者のプログラムを読む限り）

Puppeteerに移植した「魔改造bitmex_websocket」で快調に情報を収集していた時、ごくごく稀にですが「update」アクションで例外が発生していました。

更新しようとしたデータが「存在しない」ということで配列境界違反例外が発生していたのです。

運転に差し支えなかったのですが何か気持ち悪いです。
原因を調査することにしました。

プログラム中にログを散々仕込んでから運転開始。
すると次のような現象が観測されました。

注文の一生は

・insertアクションで注文発生
・updateアクションで内容更新
・leavesQty = 0 の”update”アクションにて注文終了

のはずです。
しかし、ごくごく稀に「leavesQty = 0」メッセージに続いて、通常メッセージのupdateアクションが通知されていました。
すでにデータから削除していた注文情報を更新しようとして例外を起こしていたことがわかりました。

観測したところ

・leavesQty = 0 の”update”アクションにて注文終了
・updateアクションで内容更新
・leavesQty = 0 の”update”アクションにて注文終了

のように通常のupdateアクションを挟むように終了のupdateメッセージが通知されていたのです。
2回終了が通知されているからと言って、決して注文が復活した訳では無いようです。

真相は不明です。
元々のプログラムの「leavesQty = 0」による注文終了の判断が間違っているのか、サイト側の処理の都合なのか？

しかし結果的に注文終了には変わり無いようなので、存在しない(削除された)注文への更新処理は大人の対応で「無視」することにしました。

念のためデバッグログは残しておきます。