Consecutive host configuration updates in two different sessions leads to overwriting the first update #4529

pepyakin · 2021-12-15T14:08:31Z

The affected code:

polkadot/runtime/parachains/src/configuration.rs

Lines 1074 to 1078 in cf433f5

    
           fn update_config_member(updater: impl FnOnce(&mut HostConfiguration<T::BlockNumber>) -> bool) { 
        
           	let scheduled_session = Self::scheduled_session(); 
        
           	let pending = <Self as Store>::PendingConfig::get(scheduled_session); 
        
           	let mut prev = pending.unwrap_or_else(Self::config);

Closes #4529 Closes #4533 I figured that trying to avoid updates does not really worth it to keep. This is because we seem to not update the configuration often and when we do we approach this carefully. Thus possibility of a redundant update is really negligable. At the same time, if such a redundant update does happen then the effects of that are really small: just some wasted storage interactions. On the other hand, making it work was a little bit annoying. With the proper fix for the pending updates this would be even more annoying since now we would have to add combinatorically more cases to test this. So I figured that I will just scrap that and simplify the code.

* parachains: Fix configuration module Closes #4529 Closes #4533 I figured that trying to avoid updates does not really worth it to keep. This is because we seem to not update the configuration often and when we do we approach this carefully. Thus possibility of a redundant update is really negligable. At the same time, if such a redundant update does happen then the effects of that are really small: just some wasted storage interactions. On the other hand, making it work was a little bit annoying. With the proper fix for the pending updates this would be even more annoying since now we would have to add combinatorically more cases to test this. So I figured that I will just scrap that and simplify the code. * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_configuration.rs * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/runtime_parachains_configuration.rs * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_configuration.rs * review fixes Co-authored-by: Parity Bot <[email protected]>

* parachains: Fix configuration module Closes paritytech#4529 Closes paritytech#4533 I figured that trying to avoid updates does not really worth it to keep. This is because we seem to not update the configuration often and when we do we approach this carefully. Thus possibility of a redundant update is really negligable. At the same time, if such a redundant update does happen then the effects of that are really small: just some wasted storage interactions. On the other hand, making it work was a little bit annoying. With the proper fix for the pending updates this would be even more annoying since now we would have to add combinatorically more cases to test this. So I figured that I will just scrap that and simplify the code. * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_configuration.rs * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/runtime_parachains_configuration.rs * cargo run --quiet --release --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::configuration --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_configuration.rs * review fixes Co-authored-by: Parity Bot <[email protected]>

pepyakin added the I3-bug Fails to follow expected behavior. label Dec 15, 2021

pepyakin mentioned this issue Dec 16, 2021

parachains: Fix configuration module #4540

Merged

paritytech-processbot bot closed this as completed in #4540 Dec 21, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Consecutive host configuration updates in two different sessions leads to overwriting the first update #4529

Consecutive host configuration updates in two different sessions leads to overwriting the first update #4529

pepyakin commented Dec 15, 2021

Consecutive host configuration updates in two different sessions leads to overwriting the first update #4529

Consecutive host configuration updates in two different sessions leads to overwriting the first update #4529

Comments

pepyakin commented Dec 15, 2021