Conversation
7db012a to
74b096c
Compare
| @@ -38,8 +34,9 @@ struct AbiField { | |||
| } | |||
|
|
|||
| #[derive(Debug, Clone, PartialEq, Eq, Hash, serde::Serialize, serde::Deserialize)] | |||
| pub enum SignRespondTxStatus { | |||
| Pending, | |||
| pub enum PendingRequestStatus { | |||
There was a problem hiding this comment.
I do not understand these statuses.
My understanding:
- PendingExecution
- PendingPublishSignature
- WaitingForOutcome
- PendingPublishOutcome
Maybe the names are not the best, open for discussion.
There was a problem hiding this comment.
I didn't care enough to change the Failed/Success ones. We can keep debating on what to name each of the status as we add them in on utilization
There was a problem hiding this comment.
success/failed is needed to handle different logic to create the message we are sending in read_respond depending on whether the eth tx was success or failure. It is not to represent the status of the entire bidirectional request flow.
volovyks
left a comment
There was a problem hiding this comment.
The usage of PendingRequestStatus still has mixed purposes, but we can deal with it in the followup.
c655b39
c655b39 to
7c64db4
Compare
7c64db4 to
6f99ab0
Compare
|
need another approval for this one. It's now working with the bidirectional test in #525. We do not need to wait for it to go in. This one can go in now |
This is the initial work towards
CheckpointsandPendingRequestsand is merely a refactoring right now of what we have right now.Changes
SignRespondTxIdas the id for mapping into thesign_respond_tx_map, but this changes that toSignIdsince that will be more generic going forward for all chains.SignatureGeneratortakes inCheckpointsto set it for pending publish. We're still using the old channels to send the request for publishing, but these channels will likely be moved to checkpoints in the future.RpcExecutortakes inCheckpointsto mark a request as completed (does nothing for now).