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

feat: refactor signing in order to more easily be able to dryrun #547

Merged
merged 10 commits into from
Jun 17, 2022

Conversation

daniel-savu
Copy link
Contributor

Co-authored-by: Sander Bosma sanderbosma@gmail.com
Co-authored-by: Daniel Savu savudani04@yahoo.ro

create_signed is refactored, adding support for dry_running an extrinsic before sending it.

@cla-bot-2021
Copy link

cla-bot-2021 bot commented May 19, 2022

User @savudani8, please sign the CLA here.

Co-authored-by: Sander Bosma <sanderbosma@gmail.com>
Co-authored-by: Daniel Savu <savudani04@yahoo.ro>
@daniel-savu
Copy link
Contributor Author

Looks like the clippy error is unrelated to this PR. Maybe it has to do with the used toolchain?

@jsdw
Copy link
Collaborator

jsdw commented May 20, 2022

Looks like the clippy error is unrelated to this PR. Maybe it has to do with the used toolchain?

Yup, I suspect owing to a new version of rust and such being released yesterday. I'll look into it!

subxt/src/client.rs Outdated Show resolved Hide resolved
@jsdw
Copy link
Collaborator

jsdw commented May 24, 2022

A fix for the clippy error is on it's way (#548)

I need to stare at the code a little more but offhand it looks good to me; thankyou for the PR!

@jsdw
Copy link
Collaborator

jsdw commented May 27, 2022

If you merge up from master, the clippy error should go away now!

@daniel-savu daniel-savu requested review from jsdw and lexnv June 13, 2022 13:38
subxt/src/rpc.rs Outdated
/// Returns `Ok` with an [`ApplyExtrinsicResult`], which is the result of applying of an extrinsic.
pub async fn dry_run<'client, Y, X, E, Evs>(
&self,
signed_submittable_extrinsic: &SignedSubmittableExtrinsic<'client, Y, X, E, Evs>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we only need the bytes, how about this just takes in a Vec<u8>, so we don't need the various lifetimes and generics (I'd go with a &[u8] if possible but that may be trickier)?

The SignedSubmittableExtrinsic could then return a &[u8] (give the users the option to clone or not) from the encoded() function to pass in here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, I think if we go with &[u8] here, we can use hex::encode to turn that into hex for the RPC params.

Comment on lines 450 to 452
pub fn encoded(&self) -> Encoded {
self.encoded.clone()
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As suggested in the other comment, I reckon this can return a &[u8], giving users the option to clone or not as needed. I'd add some docs too; something like:

/// Returns the SCALE encoded extrinsic bytes.

@jsdw
Copy link
Collaborator

jsdw commented Jun 13, 2022

Looking great; a couple of small suggestions but otherwise I am really liking this separation; thank you for the contribution!

@sander2
Copy link
Contributor

sander2 commented Jun 14, 2022

I haven't followed this pr too closely but in the initial commit it was possible to do create_signed().dry_run(). Now instead you need to do

let signed = create_signed();
client.rpc().dry_run(signed)

which in my opinion is a little bit less elegant. @jsdw would you be opposed to adding dry_run back into SignedSubmittableExtrinsic just as a wrapper to the one in rpc.rs?

@jsdw
Copy link
Collaborator

jsdw commented Jun 14, 2022

I'd be perfectly up for having a dry_run function on SignedSubmittableExtrinsic that calls the RPC method with the bytes it has available!

@daniel-savu
Copy link
Contributor Author

For some reason the tests are not finishing execution on my machine. I followed the GitHub workflow, including the substrate binary here, but I get this:

test client::chain_subscribe_blocks has been running for over 60 seconds
test client::chain_subscribe_finalized_blocks has been running for over 60 seconds
test client::dry_run_fails has been running for over 60 seconds
test client::dry_run_passes has been running for over 60 seconds
test client::fetch_block has been running for over 60 seconds
test client::fetch_block_hash has been running for over 60 seconds
test client::fetch_keys has been running for over 60 seconds
test client::fetch_read_proof has been running for over 60 seconds
test client::fetch_system_info has been running for over 60 seconds
test client::insert_key has been running for over 60 seconds
test client::test_iter has been running for over 60 seconds
test events::balance_transfer_subscription has been running for over 60 seconds

@jsdw
Copy link
Collaborator

jsdw commented Jun 14, 2022

One thing to do to fix the CI tests is to prepend "0x" to the hex string generated by hex::encode() (I always forget about that).

As for local tests not working, my only guess is that the substrate binary isn't on your PATH or something like that, so all of the tests are waiting for it to run (I assume no integration tests complete).

Copy link
Collaborator

@jsdw jsdw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

@jsdw jsdw merged commit cb18ad7 into paritytech:master Jun 17, 2022
@gregdhill gregdhill deleted the dryrun branch June 17, 2022 15:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants