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
When an RPC server is down or impaired (such as in Agoric/dapp-inter#199 ), there's no way for the app to detect or recover.
Description of the Design
Provide a facility in ui-kit to abstract network-config for UIs.
Provide a way for the client to request a different rpcAddr than the last request. (Maybe the client keeps track of which it tried and can ask for "other than these" or maybe the ui-kit keeps track and client can say "different than I've had yet during this session")
Some examples or abstractions for RPC retrying using a different rpcAddr.
Security Considerations
The network-config list is powerful.
Scaling Considerations
The failures may be due to rate limiting so failures shouldn't be treated as bad server.
The client shouldn't hose the servers round-robin. Something low level could ensure a limit in request rate.
Test Plan
TBD
The text was updated successfully, but these errors were encountered:
What is the Problem Being Solved?
https://main.agoric.net/network-config lists multiple
rpcAddrs
. Currently most dapps take the first (such as agoric-cli does) or a random one (such as wallet-app does).When an RPC server is down or impaired (such as in Agoric/dapp-inter#199 ), there's no way for the app to detect or recover.
Description of the Design
Provide a facility in ui-kit to abstract network-config for UIs.
Provide a way for the client to request a different rpcAddr than the last request. (Maybe the client keeps track of which it tried and can ask for "other than these" or maybe the ui-kit keeps track and client can say "different than I've had yet during this session")
Some examples or abstractions for RPC retrying using a different rpcAddr.
Security Considerations
The network-config list is powerful.
Scaling Considerations
The failures may be due to rate limiting so failures shouldn't be treated as bad server.
The client shouldn't hose the servers round-robin. Something low level could ensure a limit in request rate.
Test Plan
TBD
The text was updated successfully, but these errors were encountered: