transaction limit misses transactions

[ItsANameToo]

Describe the bug

Use the api to fetch the amount of transactions for a wallet: https://dexplorer.ark.io:8443/api/v2/wallets/DFyDKsyvR4x9D9zrfEaPmeJxSniT5N5qY8/transactions?orderBy=timestamp%3Adesc

This shows that there are 52 transactions in total. Now add a limit to it: https://dexplorer.ark.io:8443/api/v2/wallets/DFyDKsyvR4x9D9zrfEaPmeJxSniT5N5qY8/transactions?orderBy=timestamp%3Adesc&limit=10

And now it shows there are only 13 transactions

To Reproduce
Steps to reproduce the behavior:

• See above

Expected behavior
It should still show 52 transactions, but with a limit of 10 per page

[faustbrian]

Likely related to 8fc955a as we have to use estimates to not degrade performance as the vast majority of people run on potatos.

[faustbrian]

@vasild this has priority

[faustbrian]

@vasild are you working on this or not?

[vasild]

Yes, the totalCount that is returned is an estimate, so it could be inaccurate. A proper usage of that API is to cycle through the pages until a page with next: null is reached.

Notice that cycling through the pages until next: null should have been done even before 8fc955a to handle changes to the number of transactions while cycling. For example: initial page reports 30 transactions, split in 3 pages with 10 transactions each, while cycling and retrieving the second page, a new transaction is added, which now forms a 4th page with just 1 transaction. If the code used the initial estimate of 3 pages, then it would miss the last, newly added, transaction.

So, with or without 8fc955a the totalCount should be used only for visualization purposes and the actual iteration through the pages should be done until there is no next page.