Roman Bulgakov

btw, I am working on a full featured sentinel support in separate package (built on top of this one), with backoff-support and also planning to add preemptive connection reconfiguration (via...

according to this tread: http://stackoverflow.com/questions/6650940/interfaceerror-0 this is related to unreleased cursors somehow. here I must mention what I use `Manager.atomic()` context manager, maybe there is a problem in releasing cursors...

it occurs on this code (quite tricky, nested coroutines and several `atomics()`) ``` async def update(self, entity: DomainItem, existing: Item = None) -> bool: async with self._manager.atomic() as trx: existing...

according to stacktrace - it appears in case then `update` is called from within the `create` and inside of nested `atomic()` at this line: ``` 27: await self._manager.create(Item2Source, item_id=existing.id, source_id=source.id)...

looks like the issue has nothing to do with `atomic` stack.. i've refactored my code, removing nested atomics, and make the problematic call with no transaction at all, problem persists.....

so far my investigation led me to following: - this has something to do with possibly using same `connection` instance for more than one `asyncio.Task` - problem occurs only after...

my test is designed to show what bug appears in simple, real-world scenario, "crazy-monkey method" to speed up tests - is just a way of getting work done faster =)...

I might be sounding strange - but what if I need to benchmark e2e loop+function+network time for given function? for now I haven't found any other solution then either measure...

Also, not all coroutines are I/O bound - there are tons of constructions based on asyncio there code could work without I/O and coroutines are used to actually perform coprograms...

same on M2 processors also very weirdly, sometimes it is "not entirely" dead. i.e. it's being stuck launching the containers. but docker (over mounted socket) reports that networks and container...