Running try-runtime with try-state option doesn't fail

[liamaharon]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

Using the try-runtime --try-state <PALLET> flag appears to break the try-state checks in the pallet.

Originally reported in this SE question.

Steps to reproduce

No response

[Szegoo]

After doing some testing myself I realized that running try-runtime with try-state option does actually fail.

When running try-state for some specific pallet we execute the following code:

Select::Only(ref pallet_names) => {
	let try_state_fns: &[(
		&'static str,
		fn(BlockNumber, Select) -> Result<(), &'static str>,
	)] = &[for_tuples!(
		#( (<Tuple as crate::traits::PalletInfoAccess>::name(), Tuple::try_state) ),*
	)];
	let mut result = Ok(());
	for (name, try_state_fn) in try_state_fns {
		if pallet_names.iter().any(|n| n == name.as_bytes()) {
			result = result.and(try_state_fn(n.clone(), targets.clone()));
		}
	}
	result
},

The reason it did not fail is that the Collective pallet was not found anywhere inside try_state_fns, so the try-state for the Collective was never actually run.

Tbh I am not entirely sure why the Collective pallet was not found in try_state_fns since the kitchensink runtime does implement the pallet it three instances(CouncilCollective, TechnicalCollective, AllianceCollective).

I have opened a PR that adds a warning message in case the pallet provided to try-state was not found since that could save some time in the future for someone in scenarios like this. #13858

[liamaharon]

Nice catch.

To confirm, were you able to get try-state working when you used it with the name of an instantiated pallet like --try-state CouncilCollective?

[Szegoo]

To confirm, were you able to get try-state working when you used it with the name of an instantiated pallet like --try-state CouncilCollective?

No, it did not work.

[liamaharon]

Hey @Szegoo, I made a typo in my earlier comment and meant to say Council instead of CouncilCollective.

I wasn't able to replicate this on this branch using the correct name for the pallet: https://github.com/paritytech/substrate/tree/try-state-works-collective

1. substrate --dev
2. cargo run --features=try-runtime try-runtime --runtime=existing follow-chain --uri ws://localhost:9944 --try-state=Council

The name of the pallet passed to --try-state needs to match how it's specified in construct_runtime!:

Let me know if you're able to reproduce the issue using the name of the pallet as defined in construct_runtime! and I'll reopen this issue.

[Szegoo]

@liamaharon Yes, it was my fault. For some reason, I was testing with CouncilCollective 🤦.