Open crystalin opened 1 year ago
CC @kianenigma @ggwpez
Possibly fixed by paritytech/substrate#13704
Possibly fixed by paritytech/substrate#13704
any confirmation on this?
@kianenigma We didn't upgrade yet (probably another 2 months before this fix reaches prod), but the issue happened again today:
on Moonriver (Kusama) https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwss.moonriver.moonbeam.network#/referenda
{
Ongoing: {
track: 0
origin: {
system: Root
}
proposal: {
Lookup: {
hash_: 0x31b4bd6249363c0ace1bef13719d2f3b531c95ff883209ff96dbe78cb41eaf96
len: 188
}
}
enactment: {
After: 100
}
submitted: 3,867,858
submissionDeposit: {
who: 0x381d106C440F92654827D2B2c637Dd5B38A362A7
amount: 10,000,000,000,000,000,000
}
decisionDeposit: {
who: 0x381d106C440F92654827D2B2c637Dd5B38A362A7
amount: 100,000,000,000,000,000,000,000
}
deciding: {
since: 3,875,058
confirming: null
}
tally: {
ayes: 92,537,936,792,079,023,742,502
nays: 89,000,100,000,000,000,000
support: 63,219,232,282,079,023,742,502
}
inQueue: false
alarm: null
}
}
(The referenda passed the required 0.5% support some blocks before the end, but stayed in deciding)
I'm going to vote for it now to see if it moves
And it moved to confirming voting with 1 token:
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
We had a proposal that people voted for and had enough vote/support to pass at a future time. Once that time was reached, the referendum stayed in "deciding", and I also saw the scheduler being triggered earlier (by the alarm if I understood correctly). 12h later, I decided to try to vote again (with insignificant amount) and it passed it to "confirming".
Is that expected ? I thought the alarm system was there to trigger the change when the threshold was supposed to be reached
(Also, there might have been some conviction vote delegation removed after the last vote was done during the deciding period which might be the reason the alarm didn't do anything once executed)
Steps to reproduce
No response