aiohivebot isn't actually designed to run in non-life mode right now. It's designed to stream events from brand new blocks. For that, in life mode it will run 13 async tasks, one for every public API node, each doing a get_dynamic_global_properties to see if the node has any new blocks that have not and are not being processed yet, and then fetches exactly one block that is processed within its task, so the next block will likely be picked up by another node it's async task. Hence the load balancing in life mode. It also keeps track of errors and latency, so if from within the block handling other API calls are done, these will only be done to low error-rate low latency nodes. This strategy makes perfect sense in life mode, and it even works for non-life mode in terms of blocks only bots, but it doesn't really in non-life mode when I'm doing additional JSON-RPC calls (like get_ops_in_block), so I need to see how I can refactor it with the least complecity for combining both modes.
It would be cool if get_ops_in_block had a multi block too, so get_blockrange will only be part of the solution. I probably still need rate limiting when I enable virtual operations.
I have built something similar, I also checked out your bot (a while ago)... but I found it too abstract.
You probably know this, but you can get_global_properties and then (with connection still open) query the block (or the range). this results in faster times and you are less likely to be banned for too many queries within too small of an interval.
whether my bot is 1 block or 10000 blocks behind, it just uses the same function (block_range). so if for some reason, the thing isn't 'live' (yet) it just sleeps(3) and queries more.
hope that makes sense.
as for virtual ops... yeah those are kinda annoying, but for all my cases I don't need those (phew)