-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI: Encode Call & Multiple Bridge Instances. #859
Conversation
/// An index of the pallet to encode. | ||
#[structopt(skip = 255)] | ||
pallet_index: u8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's arguably a bit hacky, but the only alternative I see is to have two separate enums (one for CLI and another one for encode_call
) potentially generated by a macro to avoid duplication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure I understand what this is doing: based off the structopt
docs this is skipping pallet_index
as a CLI option and instead assigning it a default value of 255
, right?
Second of all, if that is the case I'm confused as to what problem you're addressing here by doing this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it looks like this is always overridden to 0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the thing is that this type serves two purposes:
- It's a generic (non-bridge-specific, non-chain-specific) definition of the
Call
that is used bystructopt
to generate the CLI. The user is not able to fill inpallet_index
from the CLI, hence we set it to 255 by default. - It's used as chain-specific (and bridge-specific)
encode_call
parameter. For instance we encode call that can be submitted toRialto
chain. HoweverRialto
might be bridged with multiple other chains (currently only Millau), so while encoding theBridgeSendMessage
variant we need to know which one the user meant. On the CLI level we havebridge
argument that clearly defines the bridge.
So what happens is:
structopt
parsesbridge
andcall
parameters separately.- Based on
bridge
parameter theselect_bridge
macr sets the correct generic types (Source
andTarget
). - Before calling into
Source::encode_call
we alsopreprocess_call
to add bridge-specific parameters (like thepallet_index
) which is then used internally byencode_call
.
So for an example, if we had RialtoToMillau
and RialtoToWestend
the Source
would be the same, but pallet_index
would be different, so that Rialto
's implementation of encode_call
would be able to construct different target-specific call.
While writing this I've realised that pallet_index
is actually quite misleading, so renamed it to bridge_instance_index
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the write up. The relationship between bridge
and bridge_instance_index
makes more sense now.
Changing pallet_index
to bridge_instance_index
is definitely a good call. Some of the confusion was also the use of 0
for bridge_instance_index
, but it's usage should become more clear as we add more bridges with different indices.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple of questions
/// An index of the pallet to encode. | ||
#[structopt(skip = 255)] | ||
pallet_index: u8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure I understand what this is doing: based off the structopt
docs this is skipping pallet_index
as a CLI option and instead assigning it a default value of 255
, right?
Second of all, if that is the case I'm confused as to what problem you're addressing here by doing this
pub const RIALTO_TO_MILLAU_INDEX: u8 = 0; | ||
pub const MILLAU_TO_RIALTO_INDEX: u8 = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't these need to be configurable/dynamic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These depend on the runtime configuration of specfiic source chains. So if Millau
is the first bridge pallet in Rialto
thn it's 0
index, if Rialto
was also bridged with, say, Westend
then Westend
would have index 1.
/// An index of the pallet to encode. | ||
#[structopt(skip = 255)] | ||
pallet_index: u8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it looks like this is always overridden to 0
use super::*; | ||
|
||
#[test] | ||
fn should_encode_transfer_call() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth having tests for the other supported calls?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, although note that there were no tests earlier and it's not strictly the goal of this PR. Will log it down and someone can pick it up (#863)
pub async fn run(mut self) -> anyhow::Result<()> { | ||
println!("{:?}", self.encode()?); | ||
Ok(()) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this really need to be async
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but it makes the code in src/cli/mod.rs
nicer, cause all sub-commands are expected to be async. If I could I would make it a trait, but async fn
traits are not supported yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is the async_trait
crate.
But I guess this is fine as it is, we can always change it in a different PR
* Encode Call & Multiple Bridge Instances. * Remove redundant clone. * Fix comment. * Rename pallet index bridge instance index. * Update error messages related to target instances Co-authored-by: Hernando Castano <hernando@hcastano.com>
* Encode Call & Multiple Bridge Instances. * Remove redundant clone. * Fix comment. * Rename pallet index bridge instance index. * Update error messages related to target instances Co-authored-by: Hernando Castano <hernando@hcastano.com>
Related #855
Related #854
Closes #853
This PR moves
encode-call
sub-command to it's own module and adds theselect_bridge
macro logic as well.Additionally it removes
CliChain::encode_call
(which was a temporary measure anyway) and adds a separate trait for encoding calls. Instead of selecting a network, this command is now unified and requires a bridge as well to have full bridge context. (Temporarily)preprocess_call
method is introduced to fill extra parameters that are related to specific instance of the bridge, currently we simply passbridge_pallet_index
from the context where we know which bridge we operate in.Following: rewrite of
send-message
&encod-message-payload
sub-commands and possibly fully solving #854 - I think after thispreprocess_call
will also not be required.