mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-07-10 00:37:27 +00:00
Markdown linter (#1309)
* Add markdown linting - add linter default rules - adapt rules to current code - fix the code for linting to pass - add CI check fix #1243 * Fix markdown for Substrate * Fix tooling install * Fix workflow * Add documentation * Remove trailing spaces * Update .github/.markdownlint.yaml Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Fix mangled markdown/lists * Fix captalization issues on known words
This commit is contained in:
@@ -1,6 +1,7 @@
|
||||
# Initializer Pallet
|
||||
|
||||
This module is responsible for initializing the other modules in a deterministic order. It also has one other purpose as described in the overview of the runtime: accepting and forwarding session change notifications.
|
||||
This module is responsible for initializing the other modules in a deterministic order. It also has one other purpose as
|
||||
described in the overview of the runtime: accepting and forwarding session change notifications.
|
||||
|
||||
## Storage
|
||||
|
||||
@@ -15,7 +16,9 @@ BufferedSessionChanges: Vec<(BlockNumber, ValidatorSet, ValidatorSet)>;
|
||||
|
||||
## Initialization
|
||||
|
||||
Before initializing modules, remove all changes from the `BufferedSessionChanges` with number less than or equal to the current block number, and apply the last one. The session change is applied to all modules in the same order as initialization.
|
||||
Before initializing modules, remove all changes from the `BufferedSessionChanges` with number less than or equal to the
|
||||
current block number, and apply the last one. The session change is applied to all modules in the same order as
|
||||
initialization.
|
||||
|
||||
The other parachains modules are initialized in this order:
|
||||
|
||||
@@ -30,16 +33,24 @@ The other parachains modules are initialized in this order:
|
||||
1. UMP
|
||||
1. HRMP
|
||||
|
||||
The [Configuration Module](configuration.md) is first, since all other modules need to operate under the same configuration as each other. Then the [Shared](shared.md) module is invoked, which determines the set of active validators. It would lead to inconsistency if, for example, the scheduler ran first and then the configuration was updated before the Inclusion module.
|
||||
The [Configuration Module](configuration.md) is first, since all other modules need to operate under the same
|
||||
configuration as each other. Then the [Shared](shared.md) module is invoked, which determines the set of active
|
||||
validators. It would lead to inconsistency if, for example, the scheduler ran first and then the configuration was
|
||||
updated before the Inclusion module.
|
||||
|
||||
Set `HasInitialized` to true.
|
||||
|
||||
## Session Change
|
||||
|
||||
Store the session change information in `BufferedSessionChange` along with the block number at which it was submitted, plus one. Although the expected operational parameters of the block authorship system should prevent more than one change from being buffered at any time, it may occur. Regardless, we always need to track the block number at which the session change can be applied so as to remain flexible over session change notifications being issued before or after initialization of the current block.
|
||||
Store the session change information in `BufferedSessionChange` along with the block number at which it was submitted,
|
||||
plus one. Although the expected operational parameters of the block authorship system should prevent more than one
|
||||
change from being buffered at any time, it may occur. Regardless, we always need to track the block number at which the
|
||||
session change can be applied so as to remain flexible over session change notifications being issued before or after
|
||||
initialization of the current block.
|
||||
|
||||
## Finalization
|
||||
|
||||
Finalization order is less important in this case than initialization order, so we finalize the modules in the reverse order from initialization.
|
||||
Finalization order is less important in this case than initialization order, so we finalize the modules in the reverse
|
||||
order from initialization.
|
||||
|
||||
Set `HasInitialized` to false.
|
||||
|
||||
Reference in New Issue
Block a user