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
Describe the bug
Randomly (probably depending on rpc node and loading) the InviteRepository.getInvites() function returns an incomplete list of claimed invites
To Reproduce
Steps to reproduce the behavior:
Go to 'Explore/Invite a Friend'
Click on 'Manage Invites'
Observe list of Claimed invites
Current behavior
A truncated list appears (sometimes, randomly)
A hack would be to retry the api call a few times if the "more" field is true, and hope for a full list eventually. This pattern will break on very long lists. Perhaps show a "more" indication to user if we know the list is incomplete.
Another quick fix would be to get the list in reverse order, so at least if we get a truncated return the most recent claims show up (which are most likely what the user is interested in).
The text was updated successfully, but these errors were encountered:
Describe the bug
Randomly (probably depending on rpc node and loading) the InviteRepository.getInvites() function returns an incomplete list of claimed invites
To Reproduce
Steps to reproduce the behavior:
Current behavior
A truncated list appears (sometimes, randomly)
Expected behavior
A full, scrollable list appears
Screenshots
But there are actually 22 claimed entries:
Platform & App Version
Additional context
InviteRepository.getInvites() uses a secondary index with lowerBound == upperBound.
This request pattern cannot be paginated in the normal way if the rpc node fails to return the full list (which is a completely legal response). This post suggests a workaround based on redefining the table index (uggh)
https://eosio.stackexchange.com/questions/5338/how-do-i-lookup-multiple-entries-by-same-secondary-indices-with-more-than-limit
A hack would be to retry the api call a few times if the "more" field is true, and hope for a full list eventually. This pattern will break on very long lists. Perhaps show a "more" indication to user if we know the list is incomplete.
Another quick fix would be to get the list in reverse order, so at least if we get a truncated return the most recent claims show up (which are most likely what the user is interested in).
The text was updated successfully, but these errors were encountered: