-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Running try-runtime with try-state option doesn't fail #13837
Comments
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 Tbh I am not entirely sure why the Collective pallet was not found in I have opened a PR that adds a warning message in case the pallet provided to |
Nice catch. To confirm, were you able to get |
No, it did not work. |
Hey @Szegoo, I made a typo in my earlier comment and meant to say I wasn't able to replicate this on this branch using the correct name for the pallet: https:/paritytech/substrate/tree/try-state-works-collective
The name of the pallet passed to --try-state needs to match how it's specified in Let me know if you're able to reproduce the issue using the name of the pallet as defined in |
@liamaharon Yes, it was my fault. For some reason, I was testing with |
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
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
The text was updated successfully, but these errors were encountered: