Account.history is missing operations due to wrongly estimated op numbers

[crokkon]

Expected behavior

Account.history(start, stop) with start and stop being datetime instances should return all blockchain operations from an account for the given start/stop timestamps.

Actual behavior

Account.history(start, stop) may be missing operations from the given time range

How to reproduce

I know I've created a post on 2018-02-05 14:06:54, so the account history should contain at least one comment operation on that day:

from beem.account import Account
from datetime import datetime, timedelta
from beem.utils import parse_time, addTzInfo

a = Account("stmdev")
start = addTzInfo(datetime(2018, 2, 5))
stop = addTzInfo(datetime(2018, 2, 6))
for op in a.history(start=start, stop=stop, only_ops=['comment']):
    print(op['timestamp'], op['author'], op['permlink'])

The result is empty even though there were blockchain operations from this account in the given time range.

Deeper analysis

The virtual op number estimation gives wrong results in this case. I know that this comment operation has index=2:

for op in a.get_account_history(2, 0):
    print(op['timestamp'], op['author'], op['permlink'])

2018-02-05T14:06:54 stmdev test

So a.estimate_virtual_op_num(datetime(2018, 2, 5, 14, 6, 54)) should return 2, but it actually returns 282:

from beem.account import Account
from datetime import datetime, timedelta
from beem.utils import parse_time, addTzInfo

a = Account("stmdev")
print(a.estimate_virtual_op_num(datetime(2018, 2, 5, 14, 6, 54)))

estimate_virtual_op_num has a max_count parameter that defines how many attempts beem should make before giving up. The default is 100. The limit can be disabled via max_count=-1, so beem should do as many attempts as necessary to find the according virtual op number:

a.estimate_virtual_op_num(datetime(2018, 2, 5, 14, 6, 54), max_count=-1)

This runs in an endless loop and never returns. The virtual op number estimation does not converge. The result 282 from above is just by coincidence the result after the 100th iteration for the default max_count until beem gives up. Printing out the current op num from the while loop shows that this number is oscillating and not converging towards the target value.

This behavior is the same across beem-0.19.37 up to 0.19.41, so it's not introduced from the latest changes to this function.

Environment

beempy, version 0.19.41
# python --version
Python 3.6.5