-
Notifications
You must be signed in to change notification settings - Fork 257
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
Staking support #99
Staking support #99
Conversation
I think it might be better to split the crate in to core and use the proc macros for deriving the boilerplate, as it's going to be a lot for a module like staking... |
@dvc94ch I was not aware that there were macros available, thanks! Some of the struct and type definitions were copied verbatim from the staking module in the runtime, but I can switch to using the runtime crate from |
proc macro split is merged now so can try it out here |
The proc macros seem broken. At the very least, I could not use them to obtain the validator set. |
Can you elaborate? What does cargo expand say? What exactly did you try? |
@demimarie-parity presumably #111 is what you mean |
@ascjones indeed it is. |
The proc macros are now fixed. |
This currently fails with compilation errors I do not understand.
This fixes a compile error
@dvc94ch can we go ahead and merge this as-is? This is probably the last remaining blocker for Ledgeracio. |
} | ||
|
||
#[cfg(all(test, feature = "integration-tests"))] | ||
mod tests { |
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.
Please clean up the tests before asking for a review. This is PoC-level stuff here. :)
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.
The integration-tests
feature is necessary because the tests don’t work without a running Polkadot and/or Kusama node. I could have written
#[cfg(test)]
#[cfg(feature = "integration-tests")]
or added #[cfg(feature = "integration-tests")]
on each test, but this is equivalent and shorter.
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 think he is referring to looking how it is handled already by other tests. Even better would be to add the staking module to the test runtime we use for tests
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 tried adding the staking module, but it would up pulling in a huge portion of Kusama. I think we would be better off using an actual Kusama node instead.
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 there a reason to use a feature gate instead of #[ignore]?
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, fixed.
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 also fixed the test suite to retry on temporary errors.
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 I was referring to the test code itself: it contains a bunch of my lame attempts at figuring out how to test this. It's not something we want to actually review. :/
I think @ascjones added the integration-tests
feature as a way to (eventually) run these tests in CI. There's a problem though: the contracts tests he added in #163 assumes the "remote" node has the contracts pallet, which is true for a substrate node, but isn't for polkadot/kusama. This means cargo test --feature integration-tests
will pass or fail tests depending on which flavour of node you're running. :/
@demi the retry thing doesn't actually work for me. If you use _and_watch()
and check on what the outcome actually is you'll see that it's not ok.
EDIT: I think the problem is that if you run a single node the chain isn't progressing so when we submit several extrinsics they end up failing in random order with "Extrinsic Usurped" or "Priority is too low: (1155024648500 vs 1155024648500)".
Edit-2: the contracts tests are run with the test-node
but they keep failing for me so I must be doing something wrong.
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.
EDIT: I think the problem is that if you run a single node the chain isn't progressing so when we submit several extrinsics they end up failing in random order with "Extrinsic Usurped" or "Priority is too low: (1155024648500 vs 1155024648500)"
Yeah usually that is probably because the nonce needs incrementing. I came up with a rudimentary solution here which appears to work consistently: https://github.com/paritytech/substrate-subxt/blob/aj-contract-call/src/frame/contracts.rs#L175
I tried adding the staking module, but it would up pulling in a huge portion of Kusama. I think we would be better off using an actual Kusama node instead.
I agree. I assume these tests would work against node-runtime
too? If so then #169 might be a solution.
That said for this PR I am happy for the tests to be run manually against a local node of whatever flavour.
Merge branch 'staking' of github.com:paritytech/substrate-subxt into staking * 'staking' of github.com:paritytech/substrate-subxt: Ignore the staking tests on CI Retry on temporary failures Revert "Remove unnecessary use" Remove unnecessary use Add missing docs Add SetCodeWithoutChecksCall (#166) Test chill Remove dead code Hopefully fix CI
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 think this is good enough. The tests are imperfect but I do not think this is the PR where we fix the tricky problem of solid integration testing and state setup.
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.
Looks good, just the kusama
feature needs removing I think
@@ -17,6 +17,8 @@ keywords = ["parity", "substrate", "blockchain"] | |||
include = ["Cargo.toml", "src/**/*.rs", "README.md", "LICENSE"] | |||
|
|||
[features] | |||
kusama = [] | |||
default = ["kusama"] |
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.
Why is kusama the default feature?
} | ||
|
||
/// Parachain marker struct | ||
#[cfg(feature = "kusama")] |
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.
Seems like this is used below without the feature flag so compilation might fail without the "kusama" feature?
@@ -6,6 +6,9 @@ A library to **sub**mit e**xt**rinsics to a [substrate](https://github.com/parit | |||
|
|||
See [examples](./examples). | |||
|
|||
If you use `#[derive(Call)]` without `#[module]` in the same module, you will get errors | |||
complaining about an undefined method with a name starting with `with_`. |
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've raised an issue for it to improve the error message: #170. But probably we should remove from the readme since it doesn't make sense without any context.
@@ -101,6 +101,8 @@ pub trait System { | |||
+ MaybeSerialize | |||
+ Debug | |||
+ MaybeDisplay | |||
+ Encode | |||
+ Decode |
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 think these are redundant, they come with Paramater
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.
q: Parameter
also comes with fmt::Debug
, so should I drop that too?
This is incomplete, but I would still like a review.