You are viewing a single comment's thread from:
RE: Two puzzles with the condenser_api.get_account_history call
Some time ago I had a similar observation.
I later saw an explanation from Steemchiller.
That should explain question 2.
Indirectly, this also explains question 1:
We learnt from the last error with Hivemind that the request to api.steemit.com is not only forwarded to a single server. Obviously there are several servers operating an RPC node. As Steemchiller has written, the id can differ depending on the node. The response therefore depends on the server/node to which the request was forwarded.
Thanks, I remember when you posted that, and now that I (re?)read this comment from @steemchiller, the different ID number at varying endpoints makes sense:
If steemit's endpoint relies on backend devices with different plugins and settings, that really cripples the account_history call, though. AFAIK, we should be able to iterate through that list with unique transactions from 0 through N (for whatever N is with the plugins and settings in question), right? I think that's the whole point of the paginated API methods. Yesterday, that was only possible by querying transactions one at a time. Roughly 50 transactions in that account's history were not addressable at all if the limit parameter was greater than 0. (Today, the issue seems to have cleared, at least for now.)
Maybe I should just switch to SDS for this purpose, but I was hoping to avoid reliance on a single point of failure. The idea was to let the user switch between API nodes if one goes offline. I guess the only two options for reliable data are to switch to SDS or else query the account history one transaction at a time.
I'm planning to provide a downloadable SDS version in the near future. I currently still have a few other important things on my list, but I guess we will see this being realized within the next three months.