mutil: introduce simple BlockBeat to fix itest flakes
#8717
Conversation
…ckEpoch` So the block data can be used by subsystems without calling `GetBlock`.
…tems In this commit, a minimal version of `BlockBeat` is added to synchronize block heights, which will be used in `ChainArb`, `Sweeper`, and `TxPublisher` so blocks are processed sequentially among them.
Also updated the loggings. This new state will be used in the following commit.
This commit adds a new method `handleInitialBroadcast` to handle the initial broadcast. Previously we'd broadcast immediately inside `Broadcast`, which soon will not work giving the blockbeat being used in the following commit.
Previously in `markInputFailed`, we'd remove all inputs under the same group via `removeExclusiveGroup`. This is wrong as when the current sweep fails for this input, it shouldn't affect other inputs.
…b` to use blockbeat In this commit, we replace the individual block subscription with the implementation of the interface method `ProcessBlock` so they share a single block notifier.
This commit refactors the block dispatching logic in `ChainArbitrator` so the blocks are sent concurrently to all active channel arbitrators. It also makes sure the blockbeat is now sent to channel arbitrators.
This commit changes the `activeResolvers` map so each active resolver now has a block chan to receive new blocks.
After this commit, when a new block comes, it will be passed through chainArb -> ChannelArbitrator -> resolvers.
This `immediate` flag was added as a hack so during a restart, the pending resolvers would offer the inputs to the sweeper and ask it to sweep them immediately. This is no longer need due to `blockbeat`, as now during restart, a block is always sent to all subsystems via the flow `ChainArb` -> `ChannelArb` -> resolvers -> sweeper. Thus, when there are pending inputs offered, they will be processed by the sweeper immediately.
Also updated `handlePendingSweepsReq` to skip immature inputs so the returned results are the same as those in pre-0.18.0.
The sweeper can handle the waiting so there's no need to wait for blocks inside the resolvers. By offering the inputs prior to their mature heights also guarantees the inputs with the same deadline are aggregated.
yyforyongyu
added
testing
|
Important Auto Review SkippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
|
So the basic idea is to synchronize the entire contractcourt and sweeper on each block? Do arrows in the above diagrams represent passing around the latest block info? It seems odd to have all the resolvers separately notifying the sweeper of the latest block. Is it guaranteed that a |
Yes.
It represents the timeline of the block, maybe I should try a different graph, but the block is always sent by the
Yes, when a new subscription is made via |
|
Concept ACK.
Yeah, the diagram is a bit confusing. From the code it looks like So basically flowchart LR
block([new block]) --> bb[BlockBeat]
bb --1--> c[ChainArbitrator]
bb --2--> us[UtxoSweeper]
c ~~~ us
subgraph cc[contractcourt]
c --> ca1[ChannelArb1]
c --> ca2[ChannelArb2]
c --> ca3[ChannelArb...]
ca1 ---> ar[AnchorResolver]
ca1 ---> cr[CommitResolver]
ca1 ---> hr[HtlcResolver...]
ca2 ---> rs2[Resolvers...]
ca3 ---> rs3[Resolvers...]
end
subgraph s[sweep]
us ---> b[Bumper]
end
|
Yeah exactly.
Close enough! I'd like to view sequenceDiagram
autonumber
participant bb as BlockBeat
participant cc as ChainArb
participant us as UtxoSweeper
participant tp as TxPublisher
note left of bb: 0. received block x,<br>dispatching...
note over bb,cc: 1. send block x to ChainArb,<br>wait for its done signal
bb->>cc: block x
rect rgba(165, 0, 85, 0.8)
critical signal processed
cc->>bb: processed block
option Process error or timeout
bb->>bb: error and exit
end
end
note over bb,us: 2. send block x to UtxoSweeper, wait for its done signal
bb->>us: block x
rect rgba(165, 0, 85, 0.8)
critical signal processed
us->>bb: processed block
option Process error or timeout
bb->>bb: error and exit
end
end
note over bb,tp: 3. send block x to TxPublisher, wait for its done signal
bb->>tp: block x
rect rgba(165, 0, 85, 0.8)
critical signal processed
tp->>bb: processed block
option Process error or timeout
bb->>bb: error and exit
end
end
|
|
Cool. I think this could be used to implement #8166. We would just need to make sure that the initial block is distributed by |
|
Does Suppose a conflicting transaction confirms at block But if |
|
Good question @morehouse. I need to think about it more, whether
|
I don't think so?
Conflicting transactions aren't only created by us. The counterparty can also spend HTLCs, causing conflicts. |
In an attempt to fix the itest flakes found in the sweeper/multi-hop tests, I realized there's no easy way to get around the block sync issue. In fact, I think these flakes already mean block sync may cause issues outside of the test context. Thus, a minimal version of
BlockBeatis implemented.Atm, when a new block is received, it's sent to the subsystems concurrently,
flowchart block((block)) block ---> c[ChainArb] block ---> ca1[ChannelArb1] block ---> ca2[ChannelArb2] block ---> us[UtxoSweeper] block ---> b[Bumper] block ---> ar[AnchorResolver] block ---> cr[CommitResolver] block ---> hr[HtlcResolver...]One system may process the block faster than another, causing a block sync issue.
Blockbeatwill make sure the blocks are sent in the following order,flowchart block((block)) block --> c[ChainArb] c --> ca1[ChannelArb1] c --> ca2[ChannelArb2] c --> ca3[ChannelArb...] ca1 ---> ar[AnchorResolver] ca1 ---> cr[CommitResolver] ca1 ---> hr[HtlcResolver...] ca2 ---> rs2[Resolvers...] ca3 ---> rs3[Resolvers...] ar ---> us[UtxoSweeper] cr ---> us[UtxoSweeper] hr ---> us[UtxoSweeper] rs2 ---> us[UtxoSweeper] rs3 ---> us[UtxoSweeper] us ---> b[Bumper]which means the following new behavior in the sweeper:
TODOs: