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
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: