//! Inherent extrinsics are extrinsics that are inherently added to each block. However, it is up to
//! runtime side. Any data that is required by an inherent is passed as [`InherentData`] from the
//! 1. The block producer first creates the [`InherentData`] by using the inherent data providers
//! 2. The [`InherentData`] is passed to the `inherent_extrinsics` function of the `BlockBuilder`
//! On block import the inherents in the block are checked by calling the `check_inherents` runtime
//! API. This will also pass an instance of [`InherentData`] which the runtime can use to validate
//! To provide inherent data from the client side, [`InherentDataProvider`] should be implemented.
//! /// two error modes, fatal and non-fatal errors. A fatal error means that the block is invalid
//! In the service the relevant inherent data providers need to be passed the block production and
//! the block import. As already highlighted above, the providers can be different between import
//! # async fn provide_inherent_data(&self, inherent_data: &mut InherentData) -> Result<(), sp_inherents::Error> {
//! As the inherents are created by the runtime, it depends on the runtime implementation on how
//! to create the inherents. As already described above the client side passes the [`InherentData`]
//! and expects the runtime to construct the inherents out of it. When validating the inherents,
pub fn replace_data<I: codec::Encode>(&mut self, identifier: InherentIdentifier, inherent: &I) {
/// Then there are cases where you not want the inherent check to fail, but report that there is an
/// action required. For example a timestamp of a block is in the future, the timestamp is still
/// Auxiliary to make any given error resolve to `is_fatal_error() == true` for [`IsFatalError`].