Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a state version along with every response #4186

Open
davidyuk opened this issue Aug 17, 2023 · 3 comments
Open

Provide a state version along with every response #4186

davidyuk opened this issue Aug 17, 2023 · 3 comments
Labels
need/triage New issues which need to be categorized

Comments

@davidyuk
Copy link
Member

In some cases, we are getting outdated data from the nodes behind the load balancer. It may be because there is a sync delay between nodes in normal operation, or one of the nodes can be unsynced. Half a year ago on the SDK side we introduced an exponential retry of failed requests to solve this issue aeternity/aepp-sdk-js#1744

This works well in cases when we create an entry (name, oracle), and request its details right after that. If nodes operate normally due to sync delay the new entry can be not present at one of the nodes we request then SDK would automatically retry the request several times until it gets a non-404 response.

This won't work well if one of the nodes is non-operational. Recently we got a bug when the balance in SW was flickering between 0 and an actual value probably because of this.

Another case is when we change an entry and request its details after that: the node can return outdated data and we can't notice it.

Also, this approach significantly increases the load in case we are polling not existing data (like empty account details) superhero-com/superhero-wallet#2239.

To solve the above issues I propose a different retry approach. Every node response may contain the height and microblock number. Then sdk would be able to retry the request if the response is older than the recent seen ensuring that we are working with actual data.

For example, SDK would post a NameClaim tx, then it polls transaction status, and when it gets mined aepp requests name details. If name details have an older version than the last tx poll attempt then it needs to retry or fail with "Can't get actual data error".

This approach can be spread to middleware. So, if I want to show the list of actual names I need to ensure that the response of middleware has a version greater than equal to the response with claimed transaction details. This way I won't be needed to poll names (implemented in Base aepp) or do a sophisticated check to ensure that name details are not outdated.

@davidyuk davidyuk added the need/triage New issues which need to be categorized label Aug 17, 2023
@davidyuk
Copy link
Member Author

This also can be a solution to https://github.com/aeternity/best-dev-xp-tools/issues/42

@dincho
Copy link
Member

dincho commented Aug 21, 2023

Every node response may contain the height and microblock number.

You can get that already via the API no?

In general this won't work with caching.

@davidyuk
Copy link
Member Author

We can already get height, but we can't be sure that it would be the same node as the one we ask data we need.

I got the point regarding caching. We have endpoints with immutable data like /transactions/*. If we miss some tx there to retry it would be ok, keeping caching as it is.

But some endpoints contain mutable data like /accounts/*, /names/*, still seems reasonable to provide some actuality measurement along the data. To keep them cacheable we can put only node height (changes rarer) or a synthetic number like Math.floor(microblockNumber / 5).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage New issues which need to be categorized
Projects
None yet
Development

No branches or pull requests

2 participants