-
Notifications
You must be signed in to change notification settings - Fork 2.6k
[frame/im-online] remove network state from heartbeats #14251
[frame/im-online] remove network state from heartbeats #14251
Conversation
Users should use DHT for discovering new nodes. The reason for adding external addresses was unstable work of authority discovery (see paritytech#2719), which is now stable. Hence we can safely remove `external_addresses`. Refs https://github.com/paritytech/polkadot/issues/7181
This reverts commit a282042.
They are not used for discovery, but are we sure that they are not used for something else? |
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.
LGTM code-wise, but I don't know if external addresses in heartbeats are used for anything, and it's safe to remove them.
I'm going to refer to this comment: paritytech/polkadot-sdk#646. Not merging this in the closest release is also fine with me (to give developers some time to upgrade, but we should probably notify them somehow...) |
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 to me as well but I don't know if these are used for anything else so I'd wait for someone else's approval
+ pre_upgrade and post_upgrade working fn
could @bkchr or @paritytech/frame-coders please take a look at the migration https://github.com/paritytech/substrate/pull/14251/files#diff-e8faeeb1f7c80155f21fe0f315f67a539ce51f8c08bed0d90130aae3cca6627c before we merge this? |
fn pre_upgrade() -> Result<Vec<u8>, TryRuntimeError> { | ||
ensure!(StorageVersion::get::<Pallet<T>>() == 0, "can only upgrade from version 0"); | ||
|
||
let count = v0::ReceivedHeartbeats::<T>::iter().count(); |
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 noticed there's a difference between iterating over keys and values. If so, when should I iterate over values? over keys?
const TARGET: &'static str = "runtime::im-online::migration::v1"; | ||
|
||
/// The original data layout of the im-online pallet (`ReceivedHeartbeats` storage item). | ||
mod v0 { |
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 types can just be moved to v1.
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 like that v0
emphasises previous version, which no longer exists. Also, I copied it from another frame pallet -> better to stay consistent I think
intead of using default for each field
bot merge |
Error: Github API says paritytech/polkadot#7309 is not mergeable |
bot merge |
old_received_heartbeats | ||
); | ||
} | ||
ensure!(StorageVersion::get::<Pallet<T>>() == 1, "must upgrade"); |
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.
This should have been >=
. To make it possible that CI checks not directly start to fail when v1 and a potential v2 in the future would be part of runtime.
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.
what about line 64?
ensure!(StorageVersion::get::<Pallet<T>>() == 0, "can only upgrade from version 0");
I thought if pre-upgrade fails, post-upgrade won't be executed either, no?
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.
Ahh, I also have overseen this 🙈
So, the general idea is that these migrations may stay in the runtime for quite some time and we also have tests on Polkadot that run these migrations using try runtime. Now, when the migration would be applied (which could be at any time) tests will start to fail. TLDR: The check should be removed from pre_upgrade
and changed in post as said above.
} | ||
|
||
#[cfg(test)] | ||
#[cfg(feature = "try-runtime")] |
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.
We don't set the try-runtime
feature in CI, so this will never be executed.
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.
what about try-runtime CLI cmd? Or it's not used? I've seen at least 15 migration.rs files containing that flag.
modify ensure in post_upgrade to allow for future upgrades refs paritytech#14251 (comment)
* [frame/im-online] remove ensure from pre_upgrade modify ensure in post_upgrade to allow for future upgrades refs #14251 (comment) * cargo fmt
) * [frame/im-online] remove `external_addresses` from heartbeats Users should use DHT for discovering new nodes. The reason for adding external addresses was unstable work of authority discovery (see paritytech#2719), which is now stable. Hence we can safely remove `external_addresses`. Refs https://github.com/paritytech/polkadot/issues/7181 * remove unused import * run benchmark * remove external_addresses from offchain NetworkState * add missing fn to TestNetwork * Revert "run benchmark" This reverts commit a282042. * update weights * address @bkchr comments * remove duplicate fn * cleanup benchmarking.rs * fix executor tests * remove peer_id from hearbeat as well paritytech#14251 (comment) * remove MaxPeerDataEncodingSize * change storage value type to `()` paritytech#14251 (comment) * scaffold storage migration * no need to check the type actually * remove unnecessary types from v0 mod * add a test for migration * expose Config types + pre_upgrade and post_upgrade working fn * fix test * replace dummy type with ConstU32 * add some comments to migration test * fix comment * respond to @bkchr comments * use BoundedOpaqueNetworkState::default intead of using default for each field
* [frame/im-online] remove ensure from pre_upgrade modify ensure in post_upgrade to allow for future upgrades refs paritytech#14251 (comment) * cargo fmt
Users should use DHT for discovering new nodes. The reason for adding external addresses was unstable work of authority discovery (see #2719), which is now stable. Hence we can safely remove
external_addresses
.Refs paritytech/polkadot-sdk#646
polkadot companion: paritytech/polkadot#7309