开云体育

Just tried this and I cannot reproduce what you describe. Maybe you can provide an example of the failure you experience.

Before I describe what I did, let me address the document you cite. I was not aware of this IBKR Campus course (is that the correct term ?). I generally like it since it gives newcomers to TWS API a nice overview of how various pieces fit together. Having said that, I consider it "second hand" information about TWS API. Better than "I read that on Facebook" but not authoritative. When in doubt, I look at sources in this order for authoritative information:

• Reading the TWS API source code and TWS/IBGW logs

• Reading the TWS API Guide at that is written and maintained by the TWS API developers and peer reviewed/corrected by a large group of TWS API practitioners

The IBKR Campus document seems to be pretty new (Oct 9 this year?) so it may still have some V1.00 errors. I do not know what an "error stream" is when they describe the error callback parameter reqId with "The request identifier corresponding to the most recent reqId that maintained the error stream".

Also, the first parameter for the error callback is called "id" and not "reqid" in the source code and the official TWS API Guide.

Anyway. Here is what I tried:

• I made a small client that makes native TWS API calls and does not use any of the higher level ApiController and framework functions I'd usually use
• The client side Java TWS API had version 10.17.1 and it connected to a paper account through the currently "stable" TWS 10.19.2e
• To trigger an order related error, I placed a market order for an expired ES future (ESH3, orderId = 10)
• Immediately followed by a reqPnlSingle( reqid=12345678, conid=495512552 ESZ3)

For the first test the account did not have an active ESZ3 position so reqPnlSingle would not generate any callbacks. Several runs had the same result in that the correct error message was returned with the correct orderId as the id parameter

Error. Id: 10, Code: 200, Msg: No security definition has been found for the request

I then created an ESZ3 position in the paper account for a second set of tests. Again, the client received the correct error message with the correct orderId as id parameter followed by pnl() callbacks for the ESZ3 position

11:26:32.673 [Thread-2] INFO? Daily PnL Single. Req Id: 12345678, pos: 1, daily PnL: -2, unrealizedPnL: -2, realizedPnL: , value: 209312.5

Below is the TWS API log for the second test as recorded by TWS (the first test looked exactly the same)

• The first few messages relate to the connection setup and "welcome" handshake
• TWS received the placeOrder and pnlSingle requests within the same millisecond 30.291
• Order processing and order rejection took 314ms and the error message clearly indicates orderId 10
• The first pnl callback was sent 332ms later

From all we have seen in the last few years and this quick test, I'd say there is no id parameter confusion in error callbacks, But then, my test may not be exactly what you have done.

闯ü谤驳别苍

API log taken by TWS for the second test. The first looke exactly the same just without pnl() callbacks: