0

I cloned the substrate-node-template and upgraded the dependencies to:

git = "https://github.com/paritytech/polkadot-sdk", branch = "master"

for reference, the original branch was "polkadot-v1.0.0". I have another node which was also referencing "polkadot-v1.0.0", and updated it the same way to the master branch of polkadot-sdk. my problem happens in service.rs: in substrate-node-template/service.rs, the type returned by

sc_consensus_grandpa::grandpa_peers_set_config(grandpa_protocol_name.clone())

is as expected

(NonDefaultSetConfig, Box<dyn NotificationService>)

But, in my other node, the same functions only returns the type:

NonDefaultSetConfig

and this creates a bunch of errors in service.rs. Both cargo.toml in the Node folder are identical, how is this possible? how can this be fixed? Let me know if additionnal information are needed. Thanks in advance, Kazu

1 Answer 1

1

It seems that this function was modified with this PR and it indeed has a new return type now. You might have switched to master branch in your other node before this PR was merged, so dependencies are locked with the commit that is earlier than this one. If you do cargo update in the other node, it will sync with the latest commit and it also shouldn't compile.

To fix this, you can point your dependencies to a release branch (e.g polkadot-v1.5.0), instead of master and avoid this kind of situations in the future. Or update the dependencies of substrate-node-template to specific commit that is older than this PR or the one your other node is pointing at (check in Cargo.lock for sc-network after master#):

# this will update all `polkadot-sdk` dependencies
cargo update -p sc-network --precise <commit hash>

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.