Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Extract MAX_FINALITY_LAG constant from relay_chain_selection #4788

Closed
sandreim opened this issue Jan 26, 2022 · 1 comment
Closed

Extract MAX_FINALITY_LAG constant from relay_chain_selection #4788

sandreim opened this issue Jan 26, 2022 · 1 comment
Labels
I8-refactor Code needs refactoring. U3-nice_to_have Issue is worth doing eventually.

Comments

@sandreim
Copy link
Contributor

This is related to: #4752 (comment)
We are currently duplicating the MAX_FINALITY_LAG constant in dispute-coordinator and approval-voting. We should reuse the existing one. It is also worth noting that we plan to eventually get rid of this forced finality safety net mechanism.

@sandreim sandreim added I8-refactor Code needs refactoring. Q2-easy U3-nice_to_have Issue is worth doing eventually. labels Jan 26, 2022
tifecool added a commit to tifecool/polkadot that referenced this issue Mar 18, 2022
tifecool added a commit to tifecool/polkadot that referenced this issue Mar 18, 2022
eskimor pushed a commit that referenced this issue Mar 23, 2022
* Fix for Issue #4788

* Updated fix. Moved constant to node primitives

* cargo fmt

* Update node/primitives/src/lib.rs

Co-authored-by: Andronik <write@reusable.software>

* Update node/core/dispute-coordinator/src/real/initialized.rs

Co-authored-by: Andronik <write@reusable.software>
@tifecool
Copy link
Contributor

tifecool commented Apr 2, 2022

I think this is solved.

@eskimor eskimor closed this as completed Apr 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
I8-refactor Code needs refactoring. U3-nice_to_have Issue is worth doing eventually.
Projects
None yet
Development

No branches or pull requests

3 participants