Node state for the RPC server

[IAvecilla]

What ❔

Make the ReplicaState struct and additional information about the node state available on the RPC server side.

Why ❔

For future tests, it would be necessary to have access to the state of different running nodes in order to assess the behavior of the entire consensus network. This could involve getting different metrics such as the last saved view for each node, proposals, highest vote or quorum certificate (QC), etc.

[pompon0]

You seem to expose just the view number from the replica state. Is that intended?

[IAvecilla]

You seem to expose just the view number from the replica state. Is that intended?

Yes, it is intended. In the future, we may require additional information from the storage. I've introduced another endpoint that could prove useful, especially considering the basic tests planned with the chaos-mesh tool. The intention is to incorporate more endpoints as we develop further tests and additional information from the node is needed.

[pompon0]

I mean, why not just dump the whole ReplicaState?

[IAvecilla]

I mean, why not just dump the whole ReplicaState?

Is there a way to obtain the replica state from the executor? With the latest changes to the ReplicaState, I don't see a clear way to do this. That's why I went with the solution to obtain the BlockStore and then pick the view and the last message through the CommitQC. If obtaining the replica state is indeed feasible, that would be a better approach.

[pompon0]

Is there a way to obtain the replica state from the executor? With the latest changes to the ReplicaState, I don't see a clear way to do this. That's why I went with the solution to obtain the BlockStore and then pick the view and the last message through the CommitQC. If obtaining the replica state is indeed feasible, that would be a better approach.

Right, you would need to pass ReplicaStore to the rpc server, which is not cloneable as of today. It is fine as is then.