IB証券TWSのAPIドミトリーFAQ：よくあるエラーと修正方法

2024年9月22日 00:24

こちらはIB証券（インタラクティブブローカーズ証券）のAPI情報で、公式以上に細かい点がカバーされているDmitry's TWS API FAQを日本語翻訳にかけつつ、わかりにくい部分をできる限り修正した上で魚拓保存しているものです。元のウェブページは量が多すぎて閲覧しにくく、元サイトを翻訳にかけるとPCが固まる上、最近アクセスが不安定になっているため、備忘録用に章ごとに分けて保存しています。

全体目次

TWSアプリ関連
プログラミング言語別コードサンプル
実装メモ
よくあるエラーと修正方法（このページ）
ContractDetails、Index、注文方法（共通）
コンボ注文、ブラケット注文、株式・オプション・先物注文
約定照会、デモ口座とリアル口座、グラフ化
データサブスクリプション
スキャナ、基本仕様、過去データ制約、IBゲートウェイ
FX関連、ポートフォリオ情報、その他

よくあるエラーと修正方法

[Q] 文書化されたエラーコードのリストは?

[A] IB API にあります 🙂

必ず公式 TWS API ドキュメントでエラーコードの検索を開始してください。

[Q] 取引所を指定した reqSecDefOptParms() がデータを返しません。エラーコード(321): Missing exchange for security type FUT

取引所のパラメータを指定した reqSecDefOptParms() がデータを返さないことがわかりました。ただし、取引所パラメータが空白の場合は、すべての取引所のデータが返されます。

例えばCBOE（シカゴ・オプション取引所）を指定した場合：

reqSecDefOptParams(0,"MSFT", "STK", "CBOE", 272093)

は何もデータを返しませんが、

reqSecDefOptParams(0,"MSFT", "STK", "", 272093)

は、AMEX、BOX、CBOE2、BATSなどのデータを返します。

何か間違ったことをしているのでしょうか、それとも単に壊れているのでしょうか？

リチャード

[A] by Josh (#44803)

2020 年 6 月 27 日に追加

取引所フィールドは先物/先物オプション専用であり、「FutFopExchange」というラベルが付いている必要があります。株式の場合は空白のままにする必要があります。

ジョシュ (IBKR)

—- また後ほど: リチャードからの要約 —

reqSecDefOptParams() の futFopExchange パラメーターに関して非常に非論理的な状況を要約すると、次のようになります。

ドキュメントには次のように書かれています。
"futFopExchange 返されたオプションが取引されている取引所。すべての取引所に対して空の文字列 "" に設定できます。
株式オプションではなく先物オプションにのみ適用されることについては言及されていません。パラメーターの名前がこれを暗示していると思いますが、良いドキュメントではなく、本来なら明示的に記載する必要があります。
先物オプションに対して空の文字列を設定すると、「Error 321 … Missing exchange for security type FUT」というメッセージが表示されます。
先物オプションは先物自体と同じ単一の取引所でのみ取引されるように見えるため、特定の原資産に対してこのパラメーターの選択肢は 1 つだけです。したがって、パラメータはまったく役に立ちません。
ストックオプションの空の文字列に設定すると、期待どおり、返されるすべての取引所の情報が取得されます。
ストックオプションの場合は空の文字列に設定しないと、何も表示されず、エラーさえも発生しません。

それで、これに何らかのロジックがあることがわかる人はいますか？futFopExchange パラメーターは、問題を引き起こす以外、まったく何もメリットがありません。

何かが足りないと思わずにはいられませんが、何が足りないのかわかりません…

[Q] 最新のHistorical Dataの日付が古いことがあります (私の場合はオプションのデータ)。しかし、同じデータが最新で取れることもあります。なぜ？

[A] by Jeff (#40888)

Jeff、残念ながら、最新のオプションデータをサーバーデータベースに記録する際に遅延が発生するという問題が発生している可能性があります。ステータス更新の追跡については、カスタマーサービスにお問い合わせいただくのが最善です。最近のオプションデータ (数分前) の現時点では、代わりに API リアルタイムデータ機能を使用することをお勧めします。

[Q] エラーコード (110): The price does not conform to the minimum price variation for this contract

[A] Nick 作成: (#38922)

このメッセージは、指値価格が株式の最低価格増分の倍数ではないことを意味します。たとえば、株式が 1 セント単位で取引される場合、20.153 の指値は無効になります。これは通常、移動平均などの計算から得られる価格によって発生します。

[Q] エラーコード (162): No market data permissions (一部のティッカーについては、適切なサブスクリプションがあっても発生します！)

特定のティッカーの履歴データをダウンロードできません。

Error 162, reqId 9: Historical Market Data Service error message:
No market data permissions for AMEX, ARCA, BATS, BEX, BYX, DRCTEDGE, 
EDGEA, ISLAND, NYSENAT, PSX STK, contract: Stock(symbol='sfet', 
exchange='SMART', currency='USD')

SFETは外国企業ですが、NASDAQに上場しています。昨日のIMRN（同じくNASDAQに上場）でも同じことが起こりました。以前はこのような問題はなかったと思います。

クラシックレベル 1 データを購読しています。NASDAQに上場されれば機能するはずです。

[A] by toth (#43036)

2019 年 10 月 4 日に追加

解決しました。ティッカーが取引される取引所を直接選択するだけで、データが（少なくとも部分的に）表示されます。これらのティッカーはより多くの取引所で取引されており、SMART を選択し、取引されているすべての取引所に登録していない場合、API 経由でエラーが発生したり、TWS プラットフォームでデータが遅延したりすることになります。

APIはスマートで、私が購読しているすべての取引所からデータを取得し、それに応じて集計してくれると思いましたが、1 つの取引所だけが欠けていると、すぐにエラーが表示されます。この場合、4.5ドルのレベル1 データバンドルのカバーではすべてがカバーされるわけではありません。

[Q] エラーコード (162): Historical Market Data Service error message: HMDS query returned no data: GCQ9@NYMEX Trades

[A] by Josh (#43045)

2019 年 10 月 8 日に追加

このエラーは、商品が取引されていた日付範囲外でデータが要求された場合に最もよく発生します。たとえば 7/1/19 に試してみると、データは正常に返されます。

[Q] エラーコード (162): Historical Market Data Service error message: Starting time must occur before ending time

1 秒の履歴バーをダウンロードし、ほぼ 1 年分のデータ (1 つのリクエストあたり 2000 バー、リクエスト間の間隔は 10 秒) を取得しましたが、ある時点で上記のエラーが返され始めます。リクエストに引数は「終了日」が 1 つだけで、「開始時刻」は指定していません。

[A] ドミトリー著

2020 年 3 月 8 日に追加ハッピーレディースデー! 🙂

これは「利用可能なデータがもうない」と考えてください。IB は、「HMDS query returned no data」というテキストとともに同じエラー番号 162 を返すこともありますが、これは同じ意味です。さらに何年もの履歴が必要な場合は、より大きな時間足を指定することを検討してください (1 秒バーの代わりに 1 分、10 分などを試してください)。

[Q] エラーコード (162): Historical Market Data Service error message: Scanner filter marketCapAbove is disabled

[A](#46306)

2021 年 1 月 27 日に追加

本当の答えではありませんが、スキャナー使用時に初めてエラーが発生しました。

[Q] エラーコード (200): No security definition has been found for the request

次の引数を指定してオプションを注文すると、常に 200番エラーが発生しました。

        Contract contract;
        Order order;
        contract.localSymbol = "MSFT131206P00034500";
        contract.secType = "OPT";
        contract.currency = "USD";
        contract.exchange = "SMART";

        order.action = "BUY";
        order.totalQuantity = 1000;
        order.orderType = "LMT";
        order.lmtPrice = 20.00;

        m_state = ST_PLACEORDER_ACK;

        m_pClient->placeOrder(m_orderId, contract, order);

この問題はどうすれば解決できますか? ありがとう。

以下いろいろ回答が出ていますが、私の場合はreqContractDetails()でconId（Contract ID）を取得して、conIdを使ってデータ取得や注文を行っています。conIdはアセットクラスや満期日や権利行使価格にかかわらず一意に決まっているので誤動作するリスクを回避することができます。

さーよん追記

[A1]

以下の条件を使ったreqContractDetails() で返される内容で指定していることを確認してください。

symbol="MSFT" secType="OPT" exchange="SMART" currency="USD"

あなたの場合、localSymbol="MSFT 131206P00034500" を使用することをお勧めします。

通常の場足、symbol="MSFT" を指定すればよく、この場合 (少なくとも reqHistDataでは) ここまで詳細に指定する必要はないようです。

スークメイト

また

primaryExchange = "NASDAQ" は必要ありません。

ただし、 expiry = "20131213" (YYYYMMDD) が必要です。これは reqContractDetails から出力された内容です。

スークメイト

【質問者からの返事】

こんにちは、ありがとう。placeOrder() は次のように変更したら動作するようになりました。

  contract1.secType = "OPT";
  contract1.multiplier = "100";
  contract1.exchange = "SMART";
  contract1.currency = "USD";
  contract1.includeExpired = 0;
  contract1.localSymbol = "";
  contract1.right = "Call";
  contract1.symbol = "MSFT";
  contract1.expiry = "20131206";
  contract1.strike = 36.5;

  order1.action = "BUY";
  order1.totalQuantity = 1;
  order1.orderType = "LMT";
  order1.lmtPrice = 0.2;

しかし、また行き詰まってしまいます。オプションの組み合わせを注文したいのですが、C++ ではどうすればよいでしょうか? IB の API ドキュメントは本当に最悪で、役立つ情報が見つかりません。

- - 追加の回答 - -

IB の API は本当にいらいらさせられます。同じ設定で、MSFT では注文できますが、AAPL や GOOG などでは注文できません。これは、「no security definition has been found for the request」と同じエラーです。どうやって注文すればいいのか全く分かりません。

[A3]

注文を行う前に、reqMktData (市場が閉まっている場合は reqHistData) からの出力があることを確認してください。reqContractDetails の出力はコントラクトを指定するのに役立ちます。たとえば、symbol="MSFT" secType="OPT" exchange="SMART" currency="USD" では 628 件のコントラクトを取得します。

オプション（OPT）で上記のような曖昧な指定をする場合、各権利行使価格毎のデータが返されるためこのような多数のコントラクトが返されます。コール、プットの別や、権利行使価格を指定してreqContractDetailsを使えば目的のコントラクトをピンポイントで取得できます。

さーよん追記

イギリス株のオプションなどには100件分くらいの権利行使価格が潜んでいるかも知れません。

また、デモアカウントでは一部の機能が誤動作するので注意してください。

コンボが成功したら、ぜひお知らせください。

スークメイト

[Q] エラーコード (201): Order rejected – reason:It does not comply with IB's order handling rules for derivatives that result in physical delivery

[A] by カート

API の質問ではない可能性があります。少なくとも、あなたの問題はアカウント自体の違いに関連していることは明らかのようです。解決策としては、まずはTWS で手動で注文を出して同じエラーがでるか確認してみて、アカウントの設定かAPIの問題かの区別を明確にすることをお勧めします。

-カート

原油や穀物の先物だったり、IBが現渡しをサポートしていない先物で起こる可能性のあるエラーです。

さーよん追記

[Q] エラーコード (300): Can't find EId with tickerId:40000001

2017 年 11 月 8 日に追加

[A] by Josh (#38925)

「EId が見つかりません」というエラーは通常、既にキャンセルされたサブスクリプション、または間違ったtickerIDを使用してサブスクリプションをキャンセルしようとしたときに発生します。私は Windows PCではありませんが、 Java API を試してみると問題なく動作しました。ひょっとしてデモアカウントを使っていませんか？リアルタイムバーはデモアカウントでは機能しませんでした。

ジョシュ

[Q] エラーコード (321): Error validating request:-'rc' : cause – You must specify an account

複数のアカウントを使っている場合、APIでアカウントを指定しないとこのエラーが出ます。複数のアカウントを使うケースとして、ロジックごとにアカウントを分けたり、IB証券では両建てができないので両建てするようなトレードをする場合にメリットがあります。

Javaの場合、com.ib.client.Orderクラスのaccount()メソッドでアカウントを指定できます。複数のアカウントで別々のロジックを走らせている場合、間違わないように現在TWSで使われているアカウントが合っているかフィルターをかけるようにすると安心です。

ちなみに👇の回答の「FA」は複数の顧客のためにIB証券を使っているFinancial Advisor用のアカウントを指しているので個人投資家には関係ありません。

さーよん追記

[A] by カート

FAログインがある場合は、オーダーのアカウント (またはおそらく m_account と呼ばれる) フィールドを設定する必要があります。これは、個別のサブアカウントの 1 つに設定することも、メイン F アカウント番号に「A」を追加した全アカウントに設定することもできます。

また、最後に確認したとき、アカウントフィールドは、特定の注文の placeOrder への最初の呼び出しで設定する必要があります。改造では設定できません。

誰かが、グループと割り当ても機能するようにできると言っていたと思いますが、これは何らかの理由で必要な状況で機能しなかったと思うので、もう一度試したことはなく、これについて詳しくも最新の情報もありません。

-カート

[Q] エラーコード (321): Error validating request:-'bS' : cause – Historical data queries on this contract requesting any data earlier than 199 year(s) back from now which is 18210405 00:18:14 GMT are rejected. Your query would have run from 5240807 23:29:46 UTC to 5240807 23:33:06 UTC.

[A] 明らかに reqHistoricalData の endDateTime 引数の値がおかしいので、よく確認してください。

[Q] エラーコード (321): Error validating request:-'bS' : cause – End date not supported with live updates

[A]
これは、reqHistoricalData() 呼び出しで keepUpToDate=true を使用した場合に発生する可能性があります。StackOverflowで解決策を見つけました。

引用: IB証券に問い合わせたところ、endDateTime を空白のままにすることで解決できました。

app.reqHistoricalData(app.i, contract, "","1 W", "1 day", "Adjusted_Last", 1, 1, False, [])

[Q] エラーコード (322): Error processing request. Only 50 simultaneous API historical data requests allowed

[A] ドミトリー

keep_up_to_date を true に設定した reqHistoricalData は、平均して数秒ごとに更新された時間足データを生成しますが、同時に実行できるリクエストは 50 件までです。what_to_show=BID と what_to_show=ASK のリクエストは 2 つの異なるリクエストであるため、リアルタイム BID、ASK、および TRADE をセットでリクエストする場合は、50/3 = 最大 16 コントラクトになります。

一方、reqRealTimeBars では 100 個のリクエストを同時に実行できますが、更新は厳密に 5 秒に 1 回しか提供されません。

ところで、買値/売値が必要な場合は、 what_to_show "BID_ASK" の使用を検討してください (「Historical Data Types」を参照) 。

[Q] エラーコード (456): Max number of real time requests has been reached.

[A] errorCode: '322' (上記を参照) に似ています。同時に実行されている reqRealTimeBars リクエストや reqMktData リクエストが多すぎる (100 を超えている) ようです。

[Q] エラーコード (481): Order size was reduced

私のFAアカウントでよく発生しますが、このエラーの意味と回避方法を考えた人はいますか？

面白いのは、実際に注文数の減少が起こらないことです。注文数が同じままでもエラーが出ます。

一つ気づいたことは、その時点ではかなりマージンコールに近かったということです。IB証券は私の証拠金が十分ではないと判断し、それに応じて注文数を減らそうとしたのでしょうか？

[A] by Alex (#45748)

2020 年 11 月 1 日に追加

IBから返事が来ました：

「errorCode: 481 errorMessage: Order size was reducedというコールバックは、IB 証券が貸与できる株を持っていないことが原因であることを確認しました。空売りのために顧客が借りるための株式であり、割り当て可能な貸株があればそれが割り当てられるか、注文がサーバに拒否されます。」

よって、ユーザー側ですることは何もありません。

[Q] エラーコード (???): Order Canceled – reason: Order size exceeds amount allowed by fat-finger check

[A] (2018 年 3 月 29 日)

このエラーは、TWSまたはIB Gatewayの設定では非表示にできません。ユーザーが IB証券に個別に連絡することで、ライブアカウントのファットフィンガーチェックを変更するようリクエストできます。

ファットフィンガーエラー（Fat-Finger error）とは、金融取引において誤って大量の注文を出してしまうことです。例えば、ジェイコム株大量誤発注事件で、みずほ証券の担当者が「61万円1株売り」とすべき注文を「1円61万株売り」と誤ってコンピュータに入力したケースが挙げられます。

そのような異常値による注文をシステム側で食い止めるのがファットフィンガーチェックです。TWSが実装しているセーブガードでもあるので、意図的にそういった注文を出すようなロジックを組んでいない限りは問題にならないと思います。

ちなみに言葉の由来は、その名の通り指が太いとキーボードの数字キーを打ち間違えやすく、「8」を押したのに隣のキーも押されて「89」になってしまうといったためです。

さーよん追記

[Q] エラーコード (10197): No market data during competing live session

昨夜、TWS が自動的に更新されました。ペーパーアカウント（デモ口座）からFXデータを収集するプログラムを開始したとき、リクエストに対して「No market data during competing live session」というエラーが発生しました。それ以外は正常に機能していました。一晩中リクエストしてみましたが同じエラーが発生しました。

今朝、同じコンピュータでライブアカウントにログインしましたが、エラーは発生せず、普通に収集できました。このエラーに遭遇した人はいますか？

[A] by Josh (#41512)

2021 年 1 月 15 日に追加

メッセージは、接続の遅延または市場データファームからの切断を示すものと考えられます。切断の原因によって、データが最終的に返されるタイミングは異なります。

夜間のサーバー再起動（米国東部標準時で午前0時頃）中に切断が発生するのは確実であり、必要なメンテナンスの量に応じて継続時間が異なる場合があります。

再起動後、一般的に（ただし必ずしもではない）reqMktDataサブスクリプションは自動的に再開されることが期待されます。異なるアセットクラスや取引所の市場データは、世界各地の異なるサーバーにホストされており、リセット時間が異なります。

そのため、特定の市場データファームへの接続の遅延または切断の原因を診断することをお勧めします。これにより、メッセージを受信している理由がわかります。

[A2] by rtx (#45987)

以下の手順でオプション価格をリクエストしたときにも同じエラーが起きました:

TWSにポート7497でペーパーアカウントで接続する
app.reqMarketDataType(4)
app.reqMktData(1, contract, "", False, False, [])
予想通りデータを受信する
切断する
同じスクリプトを再実行して、同じアカウントに再接続する
上記の2.と3.を繰り返す
エラー「10197 No market data during competing live session」を受信する

オプション価格ではなく株価を要求すると同じPythonスクリプトでも問題なく動作します。

ステップ5には、次の2つの処理が含まれていることを強調したいと思います。
5a. tickerIDの市場データサブスクリプションをキャンセルする: cancelMktData(1)
5b. ソケット接続を切断する: eDisconnect()

接続を閉じる前にリクエストしていたすべてのものをキャンセルするには、IBのサーバーがあなたの意図を理解し、使用されたtickerID値が解放され、再利用できるようになる必要があります。

とはいえ、私は時々、「10197 No market data during competing live session」というエラーも受け取ります。しかし、私はデモ取引口座を使用していません。代わりに、ライブ取引口座でこれを受け取りますが、アクティブな口座は1つしかありません。これまでのところ、このエラーメッセージは私の自動取引に影響を与えていないため、単に無視しています。

cancelMktData(<ticker_id>)を呼び出す前にdisconnect()を呼び出すことで、ライブ取引とペーパー取引の両方で問題が解決しました。

ライブ取引口座でエラー10197が引き続き時々返されるかどうかを確認するために、監視を続けます。

[Q] エラーコード (10225): Bust event occurred, current subscription is deactivated. Please resubscribe real-time bars immediately

[A]

TWS API v972までのバージョンでは、リアルタイムバーの購読が取引セッション中に停止することがあり、アプリケーションにエラー通知が送信されませんでした。これは、いわゆる「バスト」イベントと呼ばれる現象が原因です。

「TWS API Users Group」での回答引用:

「バストは、データストリームがバーの途中で中断または変更され、サブスクリプションがバックエンドによってキャンセルされたときに発生します。これらは比較的まれですが、残念ながら完全に回避することはできません。」

TWS API v978での改善:

TWS API v978では、バストイベントが発生した場合にアプリケーションに通知するための特別なエラーコードが追加されました。これにより、サブスクリプションを更新することが可能になりました。以下は、そのようなエラーメッセージの例です（TWS Gateway APIログから）：

15:24:00:896 -> 4-2-16777221-10225-Bust event occurred, current subscription is
 deactivated. Please resubscribe real-time bars immediately.-

1週間のテストの後、リアルタイムバーは問題なく動作しているようです。バストイベントが発生した後、再購読する際にアプリケーションで遅延を追加する必要はありません。前述のように、再購読する前に、必ず以前のサブスクリプションをキャンセルしてください。

[Q] エラーコード (1101、1102): Error validating request:-'rc' : cause – You must specify an account.

[A] Ed Gonen (2015 年 7 月 30 日に追加)

私の経験によると、深夜の TWS 切断は深夜 0 時から最初の 30 分で発生します。20分にかなり近いと思います。あなたの「5:21 London」はまさにその状況に当てはまります。私のログには通常 14 分目、つまり 12:14 が表示されます。

この状況では TWS から切断する必要はないと思います。少なくとも、私はしていません。このコードは、TWS サーバーと IB サーバー間の切断を示しており、TWS は常に自動的にそれを処理します。これは約 1 分間続きます。そして1102コードを取得します。これは、IB での長年の経験に基づいています。

[Q] エラーコード (2109): Order Event Warning:Attribute 'Outside Regular Trading Hours' is ignored based on the order type and destination. PlaceOrder is now being processed.

[A] by Josh (#40645)

これは単なる警告であり、指定された注文タイプと取引所では、rthと「outside rth」の区別がないことをお知らせするものです。これは、注文が受理されることを妨げるものではありません。株式の場合、これは通常のストップオーダーが通常の取引時間帯9:30-4:00の外側ではトリガーされないためで、トレーダーを保護するためのものです。

延長取引時間は非常に非流動的であり、通常のNBBOルールは適用されないためです。ただし、rthの外側でも有効となるストップリミットオーダーを配置することができます（ただし、この組み合わせでは非常に悪いフィルの可能性があります）。

Order Tickerの設定項目から通常の取引時間外での約定を許可することができますが、板が薄くて流動性が極端に悪いので成行注文はご法度です。略語は以下の通りで、延長取引時間は日本でいう夜間取引（PTS取引）にあたります。

rth: Regular Trading Hours（通常の取引時間）の略。
NBBO: National Best Bid and Offerの略。米国株式市場における最良売値と最良買値の情報を提供するシステム。

さーよん追記

[Q] エラーコード (2137): The closing order quantity is greater than your current position

[A] by Scott Hodson

2018 年 8 月 2 日に追加 (#40990)

2173 = クロスサイド警告: この警告メッセージは、TWS バージョン 955 以降で発生します。これは、注文によって口座のポジションがロングからショート、またはショートからロングに変更されるときに発生します。警告を回避するために、IB Gateway 956 (またはそれ以降) および TWS 957 (またはそれ以降) に新しい機能が追加され、[Global Configuration] > [Messages] に移動して「Cross Side Warning」を無効にできるようになりました。

[Q] Order size is too large IB limit is 3500

[A] by Frank Bell

取引数量の制限は、取引所や法律、IBの内部規定によって決まっており、ケースバイケースです。IBの制限に引っかかっている場合は、IBに問い合わせてみてください。

[Q] Historical Market Data Service error message: No historical market data for XAUUSD/CMDTY@CMDTYBBO Last 60

[A] (#44172)

2020 年 4 月 3 日に追加

商品取引には取引データ（エラーメッセージでいう「Last」）がないため、データタイプとしてビッド、アスク、またはミッドポイントを選択する必要があります。

TWSチャートで確認すると、異なるデータタイプが選択されており、「Trades」（取引）が含まれていないことがわかります。

[Q] 送信された注文を変更しようとすると、「Unable to modify this order as it is still being processed.」というメッセージが表示されます。

2020 年 6 月 18 日に追加

私は、初期入力後に注文のリミット価格を連続して変更しようとすると問題が発生しました。エラーは次のとおりです。

「Unable to modify this order as it is still being processed.」

私は自分が出した注文のリミット価格を追跡していますが、TWSで最後に受け入れられた値を直接知る方法はありません。（エラーメッセージを受け取って、最後に記録されたリミット価格を削除する以外では。これは非常に複雑なアプローチであり、エラーが発生しやすいように思われます。）

そこで、以下のようにして問題に対処できる方法が2つ考えられます（優先順）。

APIから最後の既知のm_lmtPriceを取得する。openOrders()はそれを返しますが、新しく提出された注文ごとに更新されません。orderStatus()は新しい注文ごとに更新されますが、m_lmtPriceを取得する方法が含まれていないようです。他に取得する方法がありますか？
リミット価格を直接追跡せず、注文ステータスに基づいて変更を送信する前に「安全」になるまで待ちます。しかし、どのステータスがリミット価格の変更を受け入れることを示しているのでしょうか？ PreSubmitted？Submitted？Inactive？ 2回目のリミット価格変更も、同じロジックが有効でしょうか？

[A] (#44735)

将来同じ問題が発生した場合に備えて、ここで私が発見したことを投稿します。基本的に、reqOpenOrders()を頻繁に呼び出さない限り、注文のリミット価格を確実に取得する方法が見つかりませんでした。それは、私のセットアップの方法にとってあまりにもエレガントではなかったので、上記の#2を選択し、注文ステータスが「Submitted」になるまで待ちました。これだけで私の目的には十分だったため、「PreSubmitted」や「Inactive」では変更を出さないようにしました。

—— また ——

参考までに、ストップリミット注文を使用している場合、注文がトリガーされるまでステータスがPreSubmittedのままになるのは正常です（'whyHeld'属性に値'trigger'が表示されます）。この状態では、リミット価格を安全に変更することができます。

この記事が気に入ったらサポートをしてみませんか？