paritytech
try-runtime: RPC endpoint / Node Integration
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.
the scenario that he is interested in is:
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.
