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
{{ message }}
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
When we do follow-chain, it would be useful to have the basic RPCs implemented and exposed on a specific port, so that you can connect PJS Apps to your fake chain.
An alternative for this is to actually integrate this in the node. #12537 envisioned that you would be able to run a node that is normally syncing, but instead of calling Core_execute_block, it would call into TryRuntime_execute_block. This would give us a fully working client.
You run execute-block or fast-forward, and once the block have all executed, you want to inspect the state.
one way to approach this is to make try-runtime cli programmable, so you can define more tests to be written, but this is a holy PITA in Rust.
an easier way, which Alan from Moonbeam is also asking is, to make the try-runtime cli capable of implementing a few important RPCs like state_getStorage and so on, and then we query it with Polkadot JS api/apps.
in principle, I think this is not hard, but I have no idea how hard it is.
So, imagine the try-runtime CLI being able to return a value to a subset of the RPC requests, namely all of the ones that can be answered by having a state.
because end of the day, try-runtime-cli is just a wrapper for remote-externalities, which is a "test state".
the problem though is that the underlying remote-ext can have a partial state etc. So there are a lot of edge cases that we may not be able to handle, and developers might confuse themselves.
For example, you would run:
try-runtime fast-forward 1000 --rpc and this will run 1000 empty blocks for you, and the process is still running, hosting an RPC server.
Activity
kianenigma commentedon Mar 8, 2023
not sure yet which is worthwhile, if any.
kianenigma commentedon Mar 14, 2023
atm it has to be either:
kianenigma commentedon Apr 6, 2023
the scenario that he is interested in is:
You run
execute-blockorfast-forward, and once the block have all executed, you want to inspect the state.one way to approach this is to make try-runtime cli programmable, so you can define more tests to be written, but this is a holy PITA in Rust.
an easier way, which Alan from Moonbeam is also asking is, to make the try-runtime cli capable of implementing a few important RPCs like
state_getStorageand so on, and then we query it with Polkadot JS api/apps.in principle, I think this is not hard, but I have no idea how hard it is.
So, imagine the try-runtime CLI being able to return a value to a subset of the RPC requests, namely all of the ones that can be answered by having a state.
because end of the day,
try-runtime-cliis just a wrapper forremote-externalities, which is a "test state".the problem though is that the underlying
remote-extcan have a partial state etc. So there are a lot of edge cases that we may not be able to handle, and developers might confuse themselves.For example, you would run:
try-runtime fast-forward 1000 --rpcand this will run 1000 empty blocks for you, and the process is still running, hosting an RPC server.liamaharon commentedon Aug 14, 2023
Moved: paritytech/try-runtime-cli#9