fix(blocksync)!: don't block in blocksync if our voting power is blocking the chain #3406

sergio-mena · 2024-07-03T10:16:04Z

Partially addresses #3415

The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height.

However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers.

Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following:

I am a node and I am starting... shall I run blocksync?
Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"

Explanation of commits:

Commit 1: e2e testbed reproducing the issue
Commit 2: commit with a trivial change to trigger e2e tests. Check the error: ❌ next to the commit hash (3fb1057)
Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that e2e are passing now.
Commit 4: revert commit2
Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason
Commit 6: Fixed unit tests

All further commits: addressing other comments and tidying up the code

PR checklist

Tests written/updated
Changelog entry added in .changelog (we use unclog to manage our changelog)
~~[ ] Updated relevant documentation (docs/ or spec/) and code comments~~
Title follows the Conventional Commits spec

This reverts commit 3fb1057.

cason

Not sure about this workaround.

We should now whether we should run block sync outside the protocol. But, ok, it works. But by changing the block Reactor constructor, we breaking a lot of code.

internal/blocksync/pool.go

internal/blocksync/reactor.go

node/setup.go

internal/blocksync/reactor.go

internal/blocksync/reactor_test.go

internal/blocksync/reactor.go

cason

I would approve, but the >=1/3 vs >2/3 question remains open.

See associated comment (line 515).

internal/blocksync/reactor.go

internal/blocksync/reactor_test.go

internal/blocksync/reactor.go

.changelog/unreleased/bug-fixes/3406-blocksync-dont-stall-if-blocking-chain.md

Co-authored-by: Daniel <daniel.cason@informal.systems>

ValarDragon

Great job!

adizere · 2024-07-04T06:22:34Z

Is this safe to backport to 0.38/v1 (post-rc1 v1)? Or better not to because it's too significant behavior change? Not trying to imply here we should backport; in favor of limiting backporting actually.

ValarDragon · 2024-07-04T06:56:28Z

I think it's definitely safe to backport, it can't really affect mainnets as you need one Val w/ over 1/3 to do anything. (And it only helps users right now if it's on the 38 line)

cason · 2024-07-04T07:21:49Z

Is this safe to backport to 0.38/v1 (post-rc1 v1)?

We need to find a solution for v0.37.x too...

sergio-mena · 2024-07-04T08:51:12Z

Is this safe to backport to 0.38/v1 (post-rc1 v1)?

To me, it's a bug, so unless there is big risk identified I'd backport it. Besides, this is clearly holding teams back, which are on v0.38.x/v0.37.x. Please reply if you don't agree.

@cason

…king the chain (#3406) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Daniel <daniel.cason@informal.systems> (cherry picked from commit bd95579) # Conflicts: # internal/blocksync/reactor.go

@cason

…king the chain (#3406) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Daniel <daniel.cason@informal.systems> (cherry picked from commit bd95579) # Conflicts: # .changelog/v0.38.3/bug-fixes/3406-blocksync-dont-stall-if-blocking-chain.md # blocksync/reactor.go # blocksync/reactor_test.go # node/node.go

@cason

…king the chain (#3406) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Daniel <daniel.cason@informal.systems> (cherry picked from commit bd95579) # Conflicts: # blocksync/reactor_test.go # internal/blocksync/reactor.go # node/node.go # node/setup.go

… is blocking the chain (#3406)" This reverts commit b069346.

@cason

…king the chain (#3406) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Daniel <daniel.cason@informal.systems>

@cason

…king the chain (backport #3406) (#3420) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request #3406 done by [Mergify](https://mergify.com). --------- Co-authored-by: Sergio Mena <sergio@informal.systems> Co-authored-by: Daniel <daniel.cason@informal.systems>

… is blocking the chain (#3406)" This reverts commit 1b99304.

@cason

…king the chain (#3406) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Daniel <daniel.cason@informal.systems>

… is blocking the chain (#3406)" This reverts commit 7f268b0.

@cason

…king the chain (#3406) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec --------- Co-authored-by: Daniel <daniel.cason@informal.systems>

@cason

…ing the chain (backport #3406) (#3421) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request #3406 done by [Mergify](https://mergify.com). --------- Co-authored-by: Sergio Mena <sergio@informal.systems> Co-authored-by: Daniel <daniel.cason@informal.systems>

@cason

…ing the chain (backport #3406) (#3422) Partially addresses #3415 The a node has no peers, blocksync gets stuck without switching to consesnus, because it needs info from other peers to have an idea of maximum height. However, there is an edge case (mainly when testing) where a validator might have >2/3 of the voting power and other validators are not started. In this case, we know we are blocking the chain, so we don't need to stay in blockchain if the only condition is that we don't have peers. Moreover, in order to block a chain, 1/3 of the voting power is enough, so the reasoning of this fix is the following: * _I am a node and I am starting... shall I run blocksync?_ * _Well, looks like I have 1/3 of the voting power (or more) at my current height... so there's no way the chain could advance in my absence... so I don't need to blocksync"_ Explanation of commits: * Commit 1: `e2e` testbed reproducing the issue * Commit 2: commit with a trivial change to trigger `e2e` tests. Check the error: ❌ next to the commit hash (3fb1057) * Commit 3: Tentative fix. Although there is a ❌ next to the commit hash (16a46ea), if you click on it, you'll see that `e2e` are passing now. * Commit 4: revert commit2 * Commit 5: Move the check for "local node is blocking the chain" outside the pool, as suggested by @cason * Commit 6: Fixed unit tests All further commits: addressing other comments and tidying up the code --- #### PR checklist - [x] Tests written/updated - [x] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ - [x] Title follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec <hr>This is an automatic backport of pull request #3406 done by [Mergify](https://mergify.com). --------- Co-authored-by: Sergio Mena <sergio@informal.systems> Co-authored-by: Daniel <daniel.cason@informal.systems>

Contributes to #3415 This is mainly refactoring to simplify `onlyValidatorIsUs` and `localNodeBlocksTheChain` (since the latter implies the former). It is a follow-up of #3406 (this is the part of #3406 that doesn't need to be backported) --- #### PR checklist - ~[ ] Tests written/updated~ - ~[ ] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog)~ - ~[ ] Updated relevant documentation (`docs/` or `spec/`) and code comments~ --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>

sergio-mena self-assigned this Jul 3, 2024

Regresssion testbed

0160866

sergio-mena force-pushed the sergio/blocksync-stalled-no-peers branch from 69ccf42 to 0160866 Compare July 3, 2024 11:54

sergio-mena added 3 commits July 3, 2024 13:59

Dummy commit to trigger e2e tests

3fb1057

Tentative fix

16a46ea

Revert "Dummy commit to trigger e2e tests"

b8fd5cf

This reverts commit 3fb1057.

cason reviewed Jul 3, 2024

View reviewed changes

internal/blocksync/pool.go Outdated Show resolved Hide resolved

internal/blocksync/reactor.go Outdated Show resolved Hide resolved

internal/blocksync/reactor.go Outdated Show resolved Hide resolved

cason reviewed Jul 3, 2024

View reviewed changes

node/setup.go Outdated Show resolved Hide resolved

cason reviewed Jul 3, 2024

View reviewed changes

node/setup.go Outdated Show resolved Hide resolved

cason reviewed Jul 3, 2024

View reviewed changes

internal/blocksync/reactor.go Outdated Show resolved Hide resolved

sergio-mena added 4 commits July 3, 2024 18:34

Moved the check for 'blocking the chain' outside the pool

b5a2c23

Fixed unit tests

464bc5b

fix units tests (leftover)

77c3fbf

Improve names, move function

c044662

sergio-mena commented Jul 3, 2024

View reviewed changes

internal/blocksync/reactor.go Outdated Show resolved Hide resolved

Update internal/blocksync/reactor.go

4bfa164

sergio-mena commented Jul 3, 2024

View reviewed changes

internal/blocksync/reactor_test.go Outdated Show resolved Hide resolved

Update internal/blocksync/reactor_test.go

257c592

sergio-mena commented Jul 3, 2024

View reviewed changes

internal/blocksync/reactor.go Outdated Show resolved Hide resolved

Add changelog

2105016

sergio-mena marked this pull request as ready for review July 3, 2024 17:55

sergio-mena requested review from a team as code owners July 3, 2024 17:55

sergio-mena added bug Something isn't working block-sync labels Jul 3, 2024

cason reviewed Jul 3, 2024

View reviewed changes

sergio-mena and others added 3 commits July 3, 2024 21:02

1/3 of the voting power is enough to block the chain

7a4753e

Rename myAddr to localAddr

ae36b45

Apply @cason's suggestions from code review

c178d1b

Co-authored-by: Daniel <daniel.cason@informal.systems>

cason mentioned this pull request Jul 3, 2024

blocksync: define the exact conditions for a node to attempt block syncing #3415

Open

4 tasks

ValarDragon approved these changes Jul 3, 2024

View reviewed changes

sergio-mena added this pull request to the merge queue Jul 4, 2024

sergio-mena added backport-to-v0.37.x Tell Mergify to backport the PR to v0.37.x backport-to-v0.38.x Tell Mergify to backport the PR to v0.38.x backport-to-v1.x Tell Mergify to backport the PR to v1.x labels Jul 4, 2024

Merged via the queue into main with commit bd95579 Jul 4, 2024
43 checks passed

sergio-mena deleted the sergio/blocksync-stalled-no-peers branch July 4, 2024 08:54

mergify bot mentioned this pull request Jul 4, 2024

fix(blocksync)!: don't block in blocksync if our voting power is blocking the chain (backport #3406) #3420

Merged

3 tasks

This was referenced Jul 4, 2024

fix(blocksync): don't block in blocksync if our voting power is blocking the chain (backport #3406) #3421

Merged

fix(blocksync): don't block in blocksync if our voting power is blocking the chain (backport #3406) #3422

Merged

sergio-mena added a commit that referenced this pull request Jul 4, 2024

Revert "fix(blocksync)!: don't block in blocksync if our voting power…

dcf9c6c

… is blocking the chain (#3406)" This reverts commit b069346.

sergio-mena added a commit that referenced this pull request Jul 5, 2024

Revert "fix(blocksync)!: don't block in blocksync if our voting power…

d8ca2c0

… is blocking the chain (#3406)" This reverts commit 1b99304.

sergio-mena added a commit that referenced this pull request Jul 5, 2024

Revert "fix(blocksync)!: don't block in blocksync if our voting power…

18cad0c

… is blocking the chain (#3406)" This reverts commit 7f268b0.

sergio-mena mentioned this pull request Aug 28, 2024

refactor(node): simplify 'node is blocking chain' logic #3885

Merged

faddat mentioned this pull request Oct 15, 2024

chore: use latest cometbft-db in v0.38.x #4296

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(blocksync)!: don't block in blocksync if our voting power is blocking the chain #3406

fix(blocksync)!: don't block in blocksync if our voting power is blocking the chain #3406

sergio-mena commented Jul 3, 2024 •

edited

Loading

cason left a comment

cason left a comment

ValarDragon left a comment

adizere commented Jul 4, 2024 •

edited

Loading

ValarDragon commented Jul 4, 2024

cason commented Jul 4, 2024

sergio-mena commented Jul 4, 2024

fix(blocksync)!: don't block in blocksync if our voting power is blocking the chain #3406

fix(blocksync)!: don't block in blocksync if our voting power is blocking the chain #3406

Conversation

sergio-mena commented Jul 3, 2024 • edited Loading

PR checklist

cason left a comment

Choose a reason for hiding this comment

cason left a comment

Choose a reason for hiding this comment

ValarDragon left a comment

Choose a reason for hiding this comment

adizere commented Jul 4, 2024 • edited Loading

ValarDragon commented Jul 4, 2024

cason commented Jul 4, 2024

sergio-mena commented Jul 4, 2024

sergio-mena commented Jul 3, 2024 •

edited

Loading

adizere commented Jul 4, 2024 •

edited

Loading