[API] get_account_history, only stop parameter appears to affect output

[bytemaster]

This issue has been fixed and the next release should have this API as well as a new, more friendly API. 

[xeroc]

We have someone testing/documenting this API as well as working on a new API that is easier.   

Thanks .. that sounds great.

But by now I am fairly sure that there is a bug in the call's implementation. Try to get all transactions from an account that has more than 100 or 200 transactions .. you will see

You also made me curious who there is that is testing and documenting the API?

[bytemaster]

We have someone testing/documenting this API as well as working on a new API that is easier.   

[xeroc]

Have you solved this issue somehow?

[monsterer]

Ok, finally figured out the parameters are not local indices on the account you specify, but global operation indices. However, I'm still seeing odd results:

Code: [Select]

{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.88751",10,"1.11.96290"]]}

leads to returning op ids 88893, 88846 and 88845, but this following call, which has been tuned to return only those results by exact index range:

Code: [Select]

{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.88845",10,"1.11.88893"]]}

leads to nothing being returned at all?

[monsterer]

The call returns ops for the given account such that

    stop < op.id <= start

except when start is 0, in which case it returns them all.  So by using operation 1, you will get no results unless the account you are querying is the account which performed operation 1.

Our API definitely has some rough edges.

Ok, so start and stop are backwards?

edit: flipping them seems to result in 0 every time...

[theoretical]

So, why if I start from operation 0 do I get results, but if I start from operation 1 I get no results?

The call returns ops for the given account such that

    stop < op.id <= start

except when start is 0, in which case it returns them all.  So by using operation 1, you will get no results unless the account you are querying is the account which performed operation 1.

Our API definitely has some rough edges.

[xeroc]

I also noticed that .. and have no answer for you as to the reason for this ..

[monsterer]

Ok, update: got the permissions set up so I can call the history method on the witness, but I'm getting confusing output:

Code: [Select]

{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.10",20,"1.11.1"]]}

returns 0 results, and

Code: [Select]

{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.10",20,"1.11.0"]]}

returns 20 results

So, why if I start from operation 0 do I get results, but if I start from operation 1 I get no results?

[monsterer]

you can access this only via websocket connection and only after requesting access to the history_api
this will not work with the cli wallet ..

the syntax for the cli wallet is different
it only takes the name and a limit

get_account_history monsterer 10

Oh wow, ok. Thanks for the update.

[xeroc]

you can access this only via websocket connection and only after requesting access to the history_api
this will not work with the cli wallet ..

the syntax for the cli wallet is different
it only takes the name and a limit

get_account_history monsterer 10

[monsterer]

try with qutotes

Code: [Select]

get_account_history "1.2.29495" "1.11.0" "100" "1.11.0"
Ref: https://github.com/xeroc/python-graphenelib/blob/master/scripts/monitor-deposits/monitor.py#L28

makes no difference

[xeroc]

try with qutotes

Code: [Select]

get_account_history "1.2.29495" "1.11.0" "100" "1.11.0"
Ref: https://github.com/xeroc/python-graphenelib/blob/master/scripts/monitor-deposits/monitor.py#L28

[monsterer]

Code: [Select]

get_account_history 1.2.29495 1.11.0 100 1.11.0
if you want to truncate to the more recent once you can change the first "1.11.0" into one of the op ids you see in the output"
the max possible number of ops is 100 afaik

Hmm, that results in:

Code: [Select]

4 parse_error_exception: Parse Error
Couldn't parse int64_t
    {}
    th_a  string.cpp:100 to_int64


[xeroc]

Code: [Select]

get_account_history 1.2.29495 1.11.0 100 1.11.0
if you want to truncate to the more recent once you can change the first "1.11.0" into one of the op ids you see in the output"
the max possible number of ops is 100 afaik

[monsterer]

Calling:

get_account_history monsterer 2 2 1
get_account_history monsterer 2 1 1
get_account_history monsterer 2 1 2

all result in the same data output. Can anyone explain how this is supposed to work?

http://docs.bitshares.eu/api/history.html

Documentation states that stop, limit and start should each affect the data returned, but that doesn't seem to be the case.