EPM and staking events improvement #13035
Conversation
gpestana
added
A0-please_review
gpestana
added
B3-apinoteworthy
and removed
B0-silent
| @@ -1130,10 +1139,8 @@ pub mod pallet { | |||
| Rewarded { account: <T as frame_system::Config>::AccountId, value: BalanceOf<T> }, | |||
| /// An account has been slashed for submitting an invalid signed submission. | |||
| Slashed { account: <T as frame_system::Config>::AccountId, value: BalanceOf<T> }, | |||
| /// The signed phase of the given round has started. | |||
| SignedPhaseStarted { round: u32 }, | |||
There was a problem hiding this comment.
These changes might break some UIs depending on these events. May be we should label it as breaking changes (E5?, B7 ) with some release notes in description.
@kianenigma might have better insights.
There was a problem hiding this comment.
I don't think any UI reads these events, so it should be okay.
Nonetheless, I would love to see Ankan's suggestions in PRs that actually do break UIs that we care about.
The broader meta-discussion here is what degree of release-note do we want to have for breaking frame changes.
I think there is a LOT LOT more that we can do here, but the current labels are barely enough to reflect changes that are relevant to parachain teams and polkadot, and for this audience I don't think this matters.
There was a problem hiding this comment.
hi,
currently the only thing you can do to highlight a code change on the release notes is elevating its upgrade criticality with the C* labels. This will change though, we're slowly implementing new labels on polkadot/substrate/cumulus that have a clear description and in future the C* labels should be used in combination with other labels so that you can distinguish what it is about upfront. Here is the documentation of the new labels explaining how they should be used: https://github.com/paritytech/labels/blob/main/docs/doc_cumulus.md
kianenigma
added
B0-silent
|
bot rebase |
|
Rebased |
|
bot merge |
paritytech-processbot
bot
deleted the
gpestana/13026-epm-staking-events
branch
* EPM and staking events improvement * Uses RawOrigin in ElectionCompute event * Refactors new phase events to PhaseTransition event * PhaseTransitioned and remove RawOrigin from event * Adds helpers for epm phase transition and staking force new * addresses review comments * nit: removes unecessary clone * fixes benchmarks Co-authored-by: parity-processbot <>
* EPM and staking events improvement * Uses RawOrigin in ElectionCompute event * Refactors new phase events to PhaseTransition event * PhaseTransitioned and remove RawOrigin from event * Adds helpers for epm phase transition and staking force new * addresses review comments * nit: removes unecessary clone * fixes benchmarks Co-authored-by: parity-processbot <>
* EPM and staking events improvement * Uses RawOrigin in ElectionCompute event * Refactors new phase events to PhaseTransition event * PhaseTransitioned and remove RawOrigin from event * Adds helpers for epm phase transition and staking force new * addresses review comments * nit: removes unecessary clone * fixes benchmarks Co-authored-by: parity-processbot <>
This PR refactors some events in the EPM pallet and staking with the goal of making it easier to trace runtime events related to the election provider and staking pallets:
EPM pallet
SolutionStored { compute, prev_ejected, origin: Option<T::AccountId> }(modified).PhaseTransitioned { from: Phase, to: Phase, round: u32}: All the phase transition events (Event::SignedPhaseStarted,Event::UnsighedPhaseStarted) are replaced by a state transition event that keep the previous and next phase. This will also allow us to easily start emitting when the emergency and phase off start and all new future phases that we may need.Staking pallet:
ForceEra { mode: Forcing }: signals that a newForcingmode was set.In addition to refactoring and adding new events, this PR also adds helper functions to transition EPM phases and set a new force era mode.
Further discussion in #13026
Closes #13026