1

I'm currently attempting to perform a migration process that involves querying events emitted from a specific pallet. The objective of this migration is to extract relevant data from these events and store it within the updated storage system. However, I've run into an error during this process.

pub fn migrate_to_v2<T: Config>() -> Weight {
    let onchain_version = Pallet::<T>::on_chain_storage_version();
    if onchain_version < 2 {
        Pallet::<T>::events().iter().for_each(|event| {
            info!(" >>> Event: {:?}", event);
        });
        Weight::zero()
    } else {
        info!(" >>> Unused migration!");
        Weight::zero()
    }
}

enter image description here

Am I doing anything wrong?

Additionally, I need to query events from a specific block. Is this feasible from a storage migration?

Edit: I'm modifying an item in my storage, switching from StorageMap to DoubleStorageMap, which necessitates a migration. The new key value used in the double map is derived from events emitted in the past. If querying past events is not possible, is there another way to achieve this?

1 Answer 1

3

You cannot query events from within the runtime. Events are meant to be pieces of information that the runtime emits outwards for the off-chain world to get easy introspection for what is happening with the runtime.
They are not meant to be used from within the runtime itself.

(As you did not include further information or source code, its not possible to help you further with this. Please consider opening another question and include all the needed info if you want more feedback on how to go about this.)

4
  • Thanks for the answer @oliver-tale-yazdi, question edited to provide more information
    – magecnion
    Commented Sep 17, 2023 at 15:05
  • As Oliver mentioned, you are not allowed to read events within the actual runtime. The amount of data in the events storage is very large, and will certainly mess up your ability to be a parachain on Polkadot. "The goal is to store certain data from these events into the updated storage." This seems like a pretty badly designed migration. Why can't you update the storage at the time that the event would be emitted, rather than trying to use events as some kind of message system to your logic?
    – Shawn Tabrizi
    Commented Sep 17, 2023 at 21:29
  • How could I store the data from the events emitted in the past if the storage item where I'm supposed to store that data only exists after the runtime upgrade? As far as I know that is not possible, maybe I missed something @ShawnTabrizi
    – magecnion
    Commented Sep 18, 2023 at 13:09
  • 1
    Storage items are just representations of writing data to a specific storage key. You can start writing to any storage as soon as you want, even before a specific storage migration, as long as your runtime logic has the logic to write to it. This is also why adding new storage items does not require any migration. So wherever you have logic where you are writing things to events, you could instead write to some storage item. Also thing about a multi-step migration. In any case, you cannot read from the events storage.
    – Shawn Tabrizi
    Commented Sep 19, 2023 at 20:14

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.