Vocs Ong

maybe its better if you share part of your code that relates to connecting.. and also share your TWS API config settings.. from what i can gather above i'm still...

Some other related TWS logs: ``` 2024-10-18 21:12:54.373 [QY] INFO [JTS-CCPDispatcherS2-41] - Error: no preferred EC for conid 730443243 no sec defs returned forSecDef reqId=PreferredReqByConid237 2024-10-18 21:12:54.373 [QY] INFO [JTS-Async-35]...

Thanks for the quick response. I did some more testing. StartupFetchNONE connected while StartupFetchALL hits the same issue I saw this fetching was merged since June, can i understand what's...

abit more isolation.. i only got the issue when i fetch executions `ib.connect('127.0.0.1', 7496, clientId=777, fetchFields=StartupFetch.EXECUTIONS, raiseSyncErrors=True )` `ConnectionError: ['executions request timed out']`

interesting, thats something new and actually insightful... so i identified its executions that's the problem.. first of all, previously i was using ib_insync.. and it doesnt have this new fetch...

follow up  so i fetched without executions and tried to call it separately.. it seems like its running forever and will never end.. I'm still somewhat guessing this is...

So i tried to interpret the API logs and did some conid search on it API Log `00:13:04:137 -> ---m7-8-734616654-SPX-OPT-20241021-5885-C-100-CBOE-USD-SPXW` TWS Log `[JTS-CCPDispatcherS24-68] - [0:178:178:1:0:61:3:WARN] EC is not known for...

some quick update.. I did secType="OPT" on the ExecutionFilter and it avoided the COMBO as i wished.. i think its an indirect effect of how ib_async doing all these passive...

i kinda need executions to better track commission/fees which logically COMBO doesnt have such data.. the individual legs are the more precise data IBKR has awful management on spread.. specifically...