?

?

?

?

On Fri, Feb 14, 2025 at 01:01 PM, Richard L King wrote:

Rather than comment on the questions you’ve raised, what I’ll do here is just lay out the basic principles that underly the order management component of my trading platform, which I have honed over the past 22 years. I believe it is immune to all the situations you describe.

?

1. Maintain a model in the client containing information about all current orders. This is the client’s view of the current state of affairs, which may not be the same as the reality at any moment because of the unavoidable asynchronicity of multiple cooperating (very) loosely--coupled components.

?

2. Record the state of the model in a persistent data store that can be used to reconstitute the model after a restart of the client (for any reason). As a matter of implementation, I use a text file containing JSON-encoded records that reflect every order-related operation or event sent to or received from the API. This ‘transaction log’ can be replayed to reconstruct the model as it was at the time the last record was written.

?

3. Update the model whenever an order is placed, modified, or cancelled.

?

4. Update the model whenever an open order, order status, execution or error notification is received from the API. Note that it is execution notifications that are really in control of order state; open order and order status notifications merely provide confirmation, and an inconsistency would be a definite fault (see 6 below).

?

5. As a practical matter, the representation of orders in the model is the actual order objects used in the place order call, updated on receipt with data from open order notifications.

?

6. If at any point an irreconcilable inconsistency emerges (for example receipt of an open order notification for an order that is no longer in the model), this is a situation that needs to be investigated (typically a programming error): execution of the client must be immediately stopped since it is not safe to proceed from an indeterminate state. (This might surprise some, but where real money is at stake it is unwise to assume that the situation will somehow correct itself.)

?

7. Provide an optional capability to ensure that every order always has a protective stop-loss. For a manual trading client, this may not be needed, because there is a least a strong possibility that there will be a human present to assess unexpected conditions and take corrective action if need be. For an unattended auto-trading system, the situation may be very different.

?

I think that more or less covers it, though there is a lot of detail I’ve glossed over.

?

Sounds like a lot of work? It is!...

?

?

Richard

?

ALERT LONG MESSAGE.

Hello Folks,

Request you to provide valuable insights on below scenarios.

Case 1:

An order modification request was placed, increasing the order size beyond the previously placed quantity. The request was successfully sent to the IBKR server, but before we could receive an Order Status Callback(from that we can extract updated Order TotalQuantity), the connection between TWS and IBKR was lost.

Despite the connection drop, the order was successfully modified at the exchange.

Scenario During Connection Loss

• If the internet was down during this period, it is possible that the order was fully executed at the exchange.

• Once the connection is restored and we request OpenOrders, we will not receive any update related to this order because it is no longer active at the exchange.

• However, when we request Executions, we will receive all partial or full executions for the order.

Problem with Execution Callback Data

• The Executions Callback does not provide the remaining order size, unlike the Order Status Callback.

• As a result, we cannot determine the actual remaining order size that was present at the exchange.

• This forces us to rely on our internal maps, which in this case would not reflect the correct remaining size of the order.

• Consequently, we may process extra executions, leading to discrepancies.

Example to Illustrate the Issue

1. Initial Order Size → 10

2. Modified Order Size → 15 (Modification was sent but confirmation was not received due to connection loss)

3. Upon reconnection:

• We do not receive an Order Status update for the modified order.

• We receive a cumulative execution size of 15, but we have no way of verifying the actual remaining order size at the time of execution.

This results in an inconsistency in tracking the order status and execution details.

Currently, each time the TWS API receives an execution update, we calculate the remaining order size as follows:

remaining_order_size = remaining_order_size - current_execution_size;

if (remaining_order_size <= 0) {

????std::cout << "Order is fully executed";

????// Remove order from metadata maps

}

if(remaining_order_size<0) remaining_order_size = 0;

To ensure proper synchronization, we need to pass the remaining order size to the Execution listeners. However, in the above logic, as soon as remaining_order_size reaches zero or a negative value, the order is immediately removed from the metadata maps.

To prevent premature removal and ensure consistency, I have implemented a safeguard by updating the order size at the time of order submission. This adjustment helps maintain synchronization and prevents potential discrepancies.

Issues in using above mechanism :(

I have identified a potential issue with updating the order size at the time of order submission. Consider the following scenario:

• A modification request is placed while the internet is down.

• At this point, we update the order size in our system to 15 (UPDATED AT THE TIME OF SENDING THE ORDER).

• Meanwhile, during the disconnection, the order is executed at the exchange for 10 units.

• Once the connection is restored, we receive only the cumulative execution size of 10 from TWS (WE ASSUMED ORDER SIZE TO BE UPDATED TO 15).

• However, since we do not receive all individual execution details, the internal system will not recognize that the order is fully executed.

As a result, the order remains in our internal maps, and we continue requesting execution details for the remaining 5 units that no longer exist.


To address this issue, we can retrieve CompletedOrders from TWS.


Any other method to handle above scenarios.?

Thanks for you patience :)

First of all, thank you for the detailed information.

To answer your question—if such a mechanism existed, I would use it to prevent any order requests (new, modify, or cancel) from being sent while the connection is down. During the 45-second interval before the disconnect callback is received, multiple requests could be placed. Once the connection is restored, I want TWS to discard all order requests made during the disconnection period, ensuring they are not sent to the IBKR server.

However, any pending orders that were already active on the exchange should remain unaffected. In essence, TWS should flush only the unsent requests while maintaining all existing orders.

Additionally, I have another question regarding the reliability of the connection loss/recovery callbacks.

Is it guaranteed that the following callbacks will always be triggered in the event of a connection loss and subsequent restoration?

• Code: 1100 – "Connectivity between IBKR and Trader Workstation has been lost."
• Code: 1102 – "Connectivity between IBKR and Trader Workstation has been restored."

I ask because, in some cases, I have manually disconnected the internet, yet I did not receive these callbacks. Could you clarify if there are scenarios where these messages might not be triggered?

Looking forward to your insights.

Hello Folks,

?

Today,?OcaType 2 works with both 10.30 and 10.34, at least in a paper trading account.?

On Tue, Feb 11, 2025 at 11:18 AM, Jimmy wrote:

Thanks for the reply 闯ü谤驳别苍.

?

At this time, I'm not modifying orders. I am just submitting two single-legged option OCA bracket orders, one with a stop price, one with a limit price.

?

I am testing using a paper trading account.

I unchecked the "bypass No Overfill Protection precaution for destinations where implied natively" checkbox in API -> precautions, but I can't get the dialog to come up again (I don't know if the behavior would be the same a live account).

?

I tested with both the current stable version (10.30.1t) and latest (10.34.1b); the results are the same

?

When submitting Option OCA orders with OcaType = 2 (which the precaution dialog implies is what is needed), they get rejected with "OCA handling method mismatch".

When using OcaType = 3, they get rejected with "Invalid parameter for OCA group for exchange SMART".

?

OcaType = 3 works fine in 10.19 and before (that's what I've always used). However, I tried OcaType = 2 with 10.19 in a live account yesterday, and I also got the same error message "Invalid parameter for OCA group for exchange SMART".

?

Is anyone else using OCA orders with options? Is it working for you in 10.30+? What OcaType are you using??

?

Thanks

Jimmy

The reqFundamentalData() does not seem to work.? I like to get the earning per share of the stock for the next three years.? What data provider do you recommend?? Thanks.

?

On Mon, Feb 10, 2025 at 07:08 PM, Jimmy wrote:

Revisiting this as the deadline to upgrade to 10.30.1t looms.

?

Raoul, my OCA orders' parent id is 0 already, so unfortunately I think the issue I'm encountering is different than what your post suggests.

?

The first time I run 10.30.1t and submit (via the API) OCA orders, a dialog comes up that says:

?

Overfill Protection Precaution

Invalid parameter for OCA group for exchange SMART. Overfill protection is implied.

Do you want to apply the correct parameter?

?

I choose yes and check "Don't display this message again".

?

Afterwards, the OCA orders get submitted, but they get rejected with "OCA handling method mismatch".

?

I brought this up with IB in October, yet the issue persists in "stable" version 10.30.1t.

?

Has anyone here figured out a solution to this "OCA handling method mismatch"?

My previous tests showed this was working in 10.32, but I will try this again tomorrow to confirm (likely in the latest offline version 10.34.1a, since 10.32 is not available anymore).

?

Thanks!

. I found the IB algo etc, but this seems to peg the order to the midpoint and changes the price based on market price changes. Within the api I'd like to give my order a start price and have the algo add say 0.1$ per second until the buy is filled. So regardless of market price changes in that one second.

Is this email intended for me?

--

Secured with Tuta Mail:

Feb 10, 2025, 01:23 by TwsApiOnGroupsIo@...:

On Sun, Feb 9, 2025 at 09:34 AM, <hadry.hamza@...> wrote:

Tws interactive brokers visual basic api question

Is it possible within the IB Api (I use? the VB version) to use an order type that based on a user set bid ( or ask ) price, walks the price up ( or down ) in preset steps until the order is filled?

Hello,

I'm trying to get the trailing trigger price for the filled trail order (not the execution price) for that I'm using the orderStatusEvent :
self.ib_client.orderStatusEvent += self.on_order_status_event

but when checking the TrailStopPrice I don't see the same price as what I see in the TWS app:
trade.order.trailStopPrice

?

?

here is what I see in the TWS app 'the price = 364.38:

?

?

Do you have any idea if this is a common issue here? and how can I get the correct information please?

?

Thanks,
Hamza

?

Hello all - I just wanted to share a bug and fix I found in the latest version. Using both the windows and mac/linux version 10.34 API, you will error out if you do: