pallet-scheduler emits CallUnavailable

[dnjscksdn98]

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

• polkadot-sdk version: v1.3.0

Eversince the pallet-preimage update has been merged, passed governance proposals (by pallet-democracy) are unable to be enacted by pallet-scheduler with an error CallUnavailable.
(Or maybe bc this PR?)

At first, I've encountered this issue on my own node, but I've also tried to reproduce the same issue with the substrate-node project. But eventually, it had the same problem.

Also, currently the polkadot JS apps page still references to the deprecated StatusFor field, so I've posted an issue on their project. (Generated preimages won't display on the page)

I just want to know if this situation is some kind of runtime configuration missing issue or really some logical issue.

Steps to reproduce

1. build the node project
   • In my case I used the substrate-node project and ran cargo build --release -p node-cli
   • It won't overwrite the previous built runtime before adding the specific package name (maybe bc native runtime removal?)
2. generate a preimage (just any simple one. I just used pallet-balances transfer)
3. submit a governance proposal
   • make it selected for the next referendum and make it pass
   • the projects LaunchPeriod, VotingPeriod, and EnactmentPeriod was too long so I reduced it to 1 minute.
4. wait until pallet-scheduler tries to call the passed proposal
   • when it finally calls the schedule, CallUnavailable will be emiitted.

[bkchr]

But the preimage is available? You checked this before?

[dnjscksdn98]

@bkchr

Yes. When I call preimage::requestStatusFor with the preimage hash it is shown as below.
But after when the proposal is scheduled, I've just found out that the Lookup len mismatches with the preimage.
On the previous version, the len field is identical with the preimage.

scheduler::agenda
[
  [
    [
      60
    ]
    [
      {
        maybeId: 0x64656d6f63726163000000000000000000000000000000000000000000000000
        priority: 63
        call: {
          Lookup: {
            hash_: 0xe0cc44c7d933a110f2b74d6040cd58c5040edb73ece1ba14a83ecf347a8e0eda
            len: 0
          }
        }
        maybePeriodic: null
        origin: {
          system: Root
        }
      }
    ]
  ]
]

preimage::requestStatusFor (0xe0cc44c7d933a110f2b74d6040cd58c5040edb73ece1ba14a83ecf347a8e0eda)
{
  Requested: {
    maybeTicket: [
      5CiPPseXPECbkjWCa6MnjNokrgYjMqmKndv2rSnekmSK2DjL
      102,000,000,000,000
    ]
    count: 1
    maybeLen: 2
  }
}

[dnjscksdn98]

I've done some more investigation, fortunately I found out that the proposal submission button in the polkadot.js app page was the main problem. At first, I just thought that only the preimage page was referencing pallet-preimage's storage, but the governance page also does. I guess this is why the len resulted to zero.

I tried to submit a proposal through the extrinsics tab and setting my parameters manually, instead of the governance page. After than, the process worked smoothly as I expected.

I guess to resolve this issue, the polkadot.js app page should be updated to not reference to the deprecated storage (pallet_preimage::StatusFor)

[ggwpez]

I guess to resolve this issue, the polkadot.js app page should be updated to not reference to the deprecated storage (pallet_preimage::StatusFor)

Yep, but that is outside of our control. Closing in favour of your other issue polkadot-js/apps#10141