Your experience may be different, but when I did it there were no code changes aside from the import and nothing broke.

?

Jason,

?

Yes. ?Also I think that what I described may be the easiest way to do that.

?

One reason is that to store level 2 data efficiently you need some kind of diff-based approach (as level 2 levels are built and change incrementally over time). ?

?

This is how level 2 data is transmitted from TWS, and ib_async is already built to maintain the level 2 levels over time from the incremental update from TWS.

?

I should add that I was easily able to overload the Connection class in connection.py to store all messages sent and received from TWS. ? I will make a separate reply summarizing that code so far.

?

-Neal

I don’t know either, but since you can request the real time level 2 data via reqMktDepth, if you were to request it and subsequently store it, would that give you what you need?

?

?

Mainly, as far as I can tell (per ), for some data historical data is not available. ?E.g. my algo uses , and I don't know how to request historical level2 data.

?

What do you gain from this approach?

If I want to backtest something, I only care about the data and my algo code; ib_async is just an interface to the brokerage and doesn’t make my algo work or not work. ?I could use ib_async to request historical data that I could save and later backtest using some replay mechanism built into the back tester.

If you are successful in recording and playing back a ‘session’, I would see you gain the ability to test whether there are bugs in ib_async or TWS/GW. ? Either of which I don’t think has anything to do with (back)testing the efficacy of your algo, does it?

?

How hard would it be to modify ib_async to record a session for playing back later? ?The motivation is that it would give a general mechanism for recording data for later use, such as backtesting. ?

?

Specifically, I would like to have a client that runs ib_async (suitably modified) for a day, subscribing to various data feeds such as ticks and level2 data (but not making any trades or other active requests that modify account state). ?I would like the modified ib_async to record all incoming messages from TWS in a file, so that later I could play the session back. ?That is, run a different client, with ib_async simulating the incoming TWS messages recorded in the file, instead of actually connecting to TWS.

?

How hard would it be to modify ib_async to allow this? ?It seems like it _might_ be relatively easy, mainly by modifying the connection class.

?

More generally, one could imagine recording a session that also included activities such as trading, and being able to replay those verbatim, with some kind of inspector that allowed one to zoom in and inspect critical moments in a session.

?

Or perhaps someone has already tried this?

?

-Neal

?

It seems this is not possible with TWS API. ?More generally, the only way to "pause" and "resume" a standing limit order seems to be to raise and lower the limit price. ?See the following topic at the TWS group for more info: /g/twsapi/topic/conditional_order_conditioned/110515714

?

-Neal

?

I am able to set the goodAfterTime field as expected for a standing order, e.g. to "20250113 15:59:00 US/Eastern", and it seems to work as expected. ?

?

However, I would also like to be able to reset the field to "", so as to remove the goodAfterTime constraint, allowing the order to fill immediately. ?I can't get this to work. ?I am able to reset the field to "", and to re-place the order, but the goodAfterTime field on the standing order is not reset. ?(See code below.)

?

(The order stays in "presubmit" status, and in the TWS GUI, if I examine the fields via the order-modification panel, it still shows the original goodAfterTime value.)

?

Checking the "audit trail" of messages through the TWS GUI, I see that the goodAfterTime field seems to transmit as a numeric field number 168.

?

As far as I can tell, even after I reset goodAfterTime, that field is not being transmitted with the new value of "".

?

I've been banging my head against this for several hours now. ? What am I doing wrong?

?

help!? ?thank you,

?

-Neal

?

Code to set the field:

Code to unset it:

I'm having some trouble getting bid/ask/last information on pre-market.
The bid/ask come as -1, and the last sometimes is not present.
I've been trying

```
contract = Stock('AAPL', 'OVERNIGHT', 'USD')
ticker = ib.reqMarketData(contract)

# The result
Ticker(contract=Stock(symbol='AAPL', exchange='OVERNIGHT', currency='USD'), time=datetime.datetime(2025, 1, 9, 14, 25, 30, 913270, tzinfo=datetime.timezone.utc), minTick=0.01, bid=-1.0, bidSize=0.0, ask=-1.0, askSize=0.0, close=242.7, bboExchange='9c0001', snapshotPermissions=3)
```
I think to get the "last", I use the specific exchange, at least looking at my previous logs I see
```
# using OVERNIGHT
Ticker(contract=Stock(symbol='RS', exchange='OVERNIGHT', currency='USD'), time=datetime.datetime(2025, 1, 8, 13, 37, 45, 829020, tzinfo=datetime.timezone.utc), minTick=0.01, bid=-1.0, bidSize=0.0, ask=-1.0, askSize=0.0, volume=49.0, close=270.11, ticks=[TickData(time=datetime.datetime(2025, 1, 8, 13, 37, 45, 829020, tzinfo=datetime.timezone.utc), tickType=8, price=-1.0, size=49.0), TickData(time=datetime.datetime(2025, 1, 8, 13, 37, 45, 829020, tzinfo=datetime.timezone.utc), tickType=9, price=270.11, size=0.0)], bboExchange='a60001', snapshotPermissions=3)

# using NYSE
Ticker(contract=Stock(symbol='RH', exchange='NYSE', currency='USD'), time=datetime.datetime(2025, 1, 8, 14, 8, 9, 599540, tzinfo=datetime.timezone.utc), minTick=0.01, bid=-1.0, bidSize=0.0, ask=-1.0, askSize=0.0, last=408.0, lastSize=1.0, volume=61.0, close=403.82, bboExchange='a60001', snapshotPermissions=3)
```

Do I need to do this some other way?
I haven't bought a level 2 subscription, do I need to buy that, and then I would have to call a different function to get the bid and ask?

Thanks for any pointer.

Yeah this is one of those edge cases that we all dread... My bot had the same issue and could not run.

?

Notice the localSymbol code allows you to break the ambiguity: one is for today, the other for tomorrow, but I don't think it can be traded since the market will be closed, so your only choice is today.

This is because IB screwed something up and marked the AM expiration as SPXW instead of SPX. Today was the first time I have ever seen this. IB support told me they were aware of the issue and were working on it. Not sure if they resolved it today or not?

Got it thanks. But it seems like there is no way for selecting contract using trading class in this case as it is SPXW for both. Only way to use contract ID and not being able to know which one is which.?

Interesting observation. Would love to have your opinions.?

?

I have been using this script to validate the option contracts using `qualifyContracts`. Today, I am getting ambiguous contracts error for this Option Contract. I know about few days when monthly and weekly expiries coincide. But, this is a different case. Both of the possible contracts suggested are SPXW trading class and the only difference is in the contract ID. Is it possible somehow that this has some relation with AM vs PM settlement? I am noticing this for first time.

?

?

?

Regards,
Pratik

?

?

You can check is_Connected() it will be true or false.

Mel

The call is: isConnected()

Using the API, what is a good way to check if the TWS is connected to IB servers?