Ewald de Wit

When canceling an ``Inactive`` order, IBKR sometimes does not send a status update back. This leaves the order hanging in the ``PendingCancel`` state forever. To prevent that, ``Inactive`` orders are...

> One solution could be to launch an asynchronous task which sleeps 3 seconds, checks the state and if it is not cancelled switches it to cancelled and emits the...

A correction to a fill is not handled properly right now: It is treated as an extra fill without discarding the erroneous older fill. This should be fixed.

> For example from very briefly looking at the code it seems that using this forces pure Python asyncio code to used. Is there a performance (or other) impact? The...

@blazespinnaker Your nested example uses coroutines that never await. You need ``await`` as a kind of portal for the flow of control to jump into other coroutines (this is just...

> My sleep above uses run, which I assumed (wrongly I guess) that it would turn control over to the event_loop similar to what happens in lua / gevent. The...

No, there's only one event loop. There's also only one queue for the scheduled callbacks. It has time/insert-order priority, so every task gets its turn - no starvation there.

> I think the confusion here is that you are saying "there are no other cooperative tasks" and I'm not sure what that means It's mentioned a few times already,...

@blazespinnaker: > ...or at at the very least it's not slicing out time to tasks already scheduled on it. Just like plain asyncio, gevent, lua, or any other type of...

The same example seems to have been re-posted, making this this whole thread a bit circular. There's still only synchronous tasks, meaning with no await in them. It has been...