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
Currently the automated chopsticks tests use configuration files with a single, hard-coded wss link as rpc endpoint.
If, for some reason, there are issues with the rpc endpoint, chopsticks will run into errors, or may just not start correctly. This then leads to test errors which more often than not are false negatives.
Instead of using a fixed wss link, we want to use a collection of wss links, with backups mirroring the ones we use in the UI .
We can attempt a connection race in a test perparation/setup script, similiar to how the XCM lib does it for the api providers, and then use the endpoints that responded to construct the configuration yaml file using the wss link of the connection that won.
The text was updated successfully, but these errors were encountered:
The main reason for adding this was to avoid errors with Astar. And while it is feasible to run these checks, starting tests against Astar's alternative rpc wss links throw an "RpcError: Response is too big" error when starting chopsticks (see error message below). Meaning even if we detect that their main rpc is down, we cannot use the alternative.
This makes checking for live wss links somewhat useless until we can rely on other rpcs (and figure out a way to check that response size won't be an issue)
$ yarn start xcm --relaychain=configs/polkadot.yml --parachain=configs/astar.yml
chopsticks xcm
XCM setup with relaychain and parachains
Options:
--version Show version number [boolean]
-h, --help Show help [boolean]
--relaychain Relaychain config file path [string]
--parachain Parachain config file path [array] [required]
RpcError: -32702: Response is too big: Exceeded max limit of 1048576
Currently the automated chopsticks tests use configuration files with a single, hard-coded wss link as rpc endpoint.
If, for some reason, there are issues with the rpc endpoint, chopsticks will run into errors, or may just not start correctly. This then leads to test errors which more often than not are false negatives.
Instead of using a fixed wss link, we want to use a collection of wss links, with backups mirroring the ones we use in the UI .
We can attempt a connection race in a test perparation/setup script, similiar to how the XCM lib does it for the api providers, and then use the endpoints that responded to construct the configuration yaml file using the wss link of the connection that won.
The text was updated successfully, but these errors were encountered: