0

We are dealing with a runtime panic. We are looking for advice on how to best debug and are looking for help to get past it.

At the change of an epoch we want a function to scan for a specific asset status and if it's there we want to initiate a series of other actions. Which might be heavy on the block transition. We will work on benchmarking as we think this is result of bad weight settings or the absence of them, but we are not sure hence this post.

The process is as following:

  1. Checks if there are the funds to bid on the asset
  2. Check if the investment conditions meet the requirements.
  3. Assemble a list of investors for that specific asset based on on-chain rules and give them a share of the assets.

The epoch changes when there are no successful actions, when there is an asset with the status finalized the runtime panics, the chain bricks stoppes just before the epoch change.

the intialization:

fn begin_block(now: T::BlockNumber) -> Weight {
        let max_block_weight: u64 = 1000;

        if (now % T::NewAssetScanPeriod::get()).is_zero() {
            Self::process_onboarded_assets();
            Self::process_finalised_assets();
        }

        max_block_weight
    }

    #[pallet::hooks]
    impl<T: Config> Hooks<BlockNumberFor<T>> for Pallet<T> {
        /// Weight: see `begin_block`
        fn on_initialize(n: T::BlockNumber) -> Weight {
            Self::begin_block(n)
        }
    }

In the node-logs the panic report is long, the main parts that reference to our code-base are the lines below. How can we best debug this?

snippet

   8: pallet_share_distributor::pallet::Pallet<T>::create_virtual
   9: <(TupleElement0,) as frame_support::traits::hooks::OnInitialize<BlockNumber>>::on_initialize
...
Thread 'tokio-runtime-worker' panicked at 'called `Option::unwrap()` on a `None` value', /Users/ilhan/dev/fair-squares/pallets/share_distributor/src/functions.rs:63

The code-block the tokio-runtime-worker panicked is:

///Collect contributors to the bid, and their shares
pub fn owner_and_shares(collection_id: T::NftCollectionId, item_id: T::NftItemId) -> Vec<(T::AccountId, Percent)>{

    //Get owners and their reserved contribution to the bid
    
    let reservation_infos = HousingFund::Reservations::<T>::get((collection_id,item_id)).unwrap();
    let vec0 = reservation_infos.contributions;
    let price = reservation_infos.amount;
    let mut vec = Vec::new() ;
    for i in vec0.iter(){
        let price0 = Self::balance_to_u64_option(price).unwrap();
        let contribution = Self::balance_to_u64_option(i.1).unwrap();
        let share = Percent::from_rational(contribution,price0);
        debug_assert!(!share.is_zero()); 
        vec.push((i.0.clone(),share));
        //Update Virtual_account storage
        Virtual::<T>::mutate(collection_id,item_id,|val|{
            let mut val0 = val.clone().unwrap();
            val0.owners.push(i.0.clone());
            *val = Some(val0);

        }); 

    }
    vec
}

Full logs can be found here. The pallet we think is the issue resides in is can be found in our repo

1 Answer 1

0

So the problem of this issue was about the logic we had defined and not about the weights or anything else. The finalization call we made should not have taken place, before the status of an asset had the onboarded status and an investorsList was created. So it was not about the hook itself. The use-case panicked the runtime.

1

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.