Trait sc_client_api::backend::Finalizer [−][src]
pub trait Finalizer<Block: BlockT, B: Backend<Block>> { fn apply_finality(
&self,
operation: &mut ClientImportOperation<Block, B>,
id: BlockId<Block>,
justification: Option<Justification>,
notify: bool
) -> Result<()>; fn finalize_block(
&self,
id: BlockId<Block>,
justification: Option<Justification>,
notify: bool
) -> Result<()>; }
Expand description
Finalize Facilities
Required methods
fn apply_finality(
&self,
operation: &mut ClientImportOperation<Block, B>,
id: BlockId<Block>,
justification: Option<Justification>,
notify: bool
) -> Result<()>
fn apply_finality(
&self,
operation: &mut ClientImportOperation<Block, B>,
id: BlockId<Block>,
justification: Option<Justification>,
notify: bool
) -> Result<()>
Mark all blocks up to given as finalized in operation.
If justification
is provided it is stored with the given finalized
block (any other finalized blocks are left unjustified).
If the block being finalized is on a different fork from the current
best block the finalized block is set as best, this might be slightly
inaccurate (i.e. outdated). Usages that require determining an accurate
best block should use SelectChain
instead of the client.
fn finalize_block(
&self,
id: BlockId<Block>,
justification: Option<Justification>,
notify: bool
) -> Result<()>
fn finalize_block(
&self,
id: BlockId<Block>,
justification: Option<Justification>,
notify: bool
) -> Result<()>
Finalize a block.
This will implicitly finalize all blocks up to it and fire finality notifications.
If the block being finalized is on a different fork from the current
best block, the finalized block is set as best. This might be slightly
inaccurate (i.e. outdated). Usages that require determining an accurate
best block should use SelectChain
instead of the client.
Pass a flag to indicate whether finality notifications should be propagated. This is usually tied to some synchronization state, where we don’t send notifications while performing major synchronization work.