You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The API spec. shows response for "Get tx history by block height" should include two fields named "start" and a "total". However, actual responses do not include these fields. These fields are useful to iterate through pages of transactions. The issue has a low impact however as there are some workarounds available.
Expected behaviour
Response for "Get tx history by block height" should include "total" and "start" fields
User expects some fields to be present to indicate if more data are available (eg. total). As these fields are missing, a workaround must be used to determine if all available data have been fetched. This workaround is not perfect and can lead to errors.
Possible workaround
Extract the idx value of the last transaction in the transactions history (= index)
If index is lesser than (cursor + size - 1), this means more pages of data might be available. Therefore, users should send a new request to get the next page of data.
This workaround can lead to error in case the requested next page of data contains 0 transactions. The following examples show what issues the workaround might cause.
Other related issue: The API specification is inaccurate. The example provided in the specification is quite different from the actual responses (see above)
Summary
The API spec. shows response for "Get tx history by block height" should include two fields named "start" and a "total". However, actual responses do not include these fields. These fields are useful to iterate through pages of transactions. The issue has a low impact however as there are some workarounds available.
Expected behaviour
Response for "Get tx history by block height" should include "total" and "start" fields
Reproduce
Here is how I call the API:
Here is the response body I get:
Impact
User expects some fields to be present to indicate if more data are available (eg. total). As these fields are missing, a workaround must be used to determine if all available data have been fetched. This workaround is not perfect and can lead to errors.
Possible workaround
This workaround can lead to error in case the requested next page of data contains 0 transactions. The following examples show what issues the workaround might cause.
Get all available transactions:
As the last idx (6138) is not lesser than (cursor=0 + size=6139 - 1), user will send a second request to check if more data are available:
The second request will return an error like the following which does not clearly indicate no more data are available:
Conclusion
Please, ensures "total" and "start" fields are present in responses of paginated API operations :)
The text was updated successfully, but these errors were encountered: