Skip to content
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

Merged
merged 8 commits into from
Apr 5, 2021
Merged

Conversation

tomusdrw
Copy link
Contributor

@tomusdrw tomusdrw commented Apr 2, 2021

Related #855
Related #854
Closes #853

This PR moves encode-call sub-command to it's own module and adds the select_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 pass bridge_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 this preprocess_call will also not be required.

Comment on lines 63 to 65
/// An index of the pallet to encode.
#[structopt(skip = 255)]
pallet_index: u8,
Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor Author

@tomusdrw tomusdrw Apr 3, 2021

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:

  1. It's a generic (non-bridge-specific, non-chain-specific) definition of the Call that is used by structopt to generate the CLI. The user is not able to fill in pallet_index from the CLI, hence we set it to 255 by default.
  2. It's used as chain-specific (and bridge-specific) encode_call parameter. For instance we encode call that can be submitted to Rialto chain. However Rialto might be bridged with multiple other chains (currently only Millau), so while encoding the BridgeSendMessage variant we need to know which one the user meant. On the CLI level we have bridge argument that clearly defines the bridge.

So what happens is:

  1. structopt parses bridge and call parameters separately.
  2. Based on bridge parameter the select_bridge macr sets the correct generic types (Source and Target).
  3. Before calling into Source::encode_call we also preprocess_call to add bridge-specific parameters (like the pallet_index) which is then used internally by encode_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.

Copy link
Contributor

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.

@tomusdrw tomusdrw changed the title Encode Call & Multiple Bridge Instances. CLI: Encode Call & Multiple Bridge Instances. Apr 2, 2021
Copy link
Contributor

@HCastano HCastano left a 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

relays/bin-substrate/src/cli/encode_call.rs Outdated Show resolved Hide resolved
Comment on lines 63 to 65
/// An index of the pallet to encode.
#[structopt(skip = 255)]
pallet_index: u8,
Copy link
Contributor

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

Comment on lines +106 to +107
pub const RIALTO_TO_MILLAU_INDEX: u8 = 0;
pub const MILLAU_TO_RIALTO_INDEX: u8 = 0;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Comment on lines 63 to 65
/// An index of the pallet to encode.
#[structopt(skip = 255)]
pallet_index: u8,
Copy link
Contributor

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() {
Copy link
Contributor

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?

Copy link
Contributor Author

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)

Comment on lines +145 to +148
pub async fn run(mut self) -> anyhow::Result<()> {
println!("{:?}", self.encode()?);
Ok(())
}
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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

@HCastano HCastano enabled auto-merge (squash) April 5, 2021 17:08
@HCastano HCastano merged commit 4d30e66 into master Apr 5, 2021
@HCastano HCastano deleted the td-relay-encode branch April 5, 2021 17:48
serban300 pushed a commit to serban300/parity-bridges-common that referenced this pull request Mar 27, 2024
* 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>
serban300 pushed a commit to serban300/parity-bridges-common that referenced this pull request Apr 8, 2024
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support sending messages to multiple bridges.
2 participants