Open JssDWt opened 1 year ago
Could you turn on debug log for CNCT
and collect some relevant logs? My suspicion is, since the dust HTLCs are never sent to chain or settled, once timed out, they are left on the commitment forever as we forgot to clean them.
Could you turn on debug log for
CNCT
and collect some relevant logs? My suspicion is, since the dust HTLCs are never sent to chain or settled, once timed out, they are left on the commitment forever as we forgot to clean them.
I think we can do that. How much impact to you think that will have on the amount of logs produced? I looked at the debug statements and it doesn't look too bad at first glance?
It depends. I think if you turn on debug logging of CNCT
for several blocks should be enough to collect the info we need here.
@yyforyongyu These are CNCT logs from a specific channelpoint. These logs repeat for every block:
2023-01-31 04:26:30.243 [DBG] CNCT: ChannelArbitrator(CHANNELPOINT_A_REDACTED:0): attempting state step with trigger=chainTrigger from state=StateDefault
2023-01-31 04:26:30.299 [DBG] CNCT: ChannelArbitrator(CHANNELPOINT_A_REDACTED:0): new block (height=774416) examining active HTLC's
2023-01-31 04:26:30.520 [DBG] CNCT: ChannelArbitrator(CHANNELPOINT_A_REDACTED:0): checking commit chain actions at height=774416, in_htlc_count=1, out_htlc_count=0
2023-01-31 04:26:30.723 [INF] CNCT: ChannelArbitrator(CHANNELPOINT_A_REDACTED:0): go to chain for incoming htlc HTLC_ID_A_REDACTED: timeout=659057, blocks_until_expiry=4294851937, broadcast_delta=10
2023-01-31 04:26:31.295 [DBG] CNCT: ChannelArbitrator(CHANNELPOINT_A_REDACTED:0): no resolution needed for incoming dust htlc=HTLC_ID_A_REDACTED
2023-01-31 04:26:31.469 [DBG] CNCT: ChannelArbitrator(CHANNELPOINT_A_REDACTED:0): no actions for chain trigger, terminating
2023-01-31 04:26:31.589 [DBG] CNCT: ChannelArbitrator(CHANNELPOINT_A_REDACTED:0): terminating at state=StateDefault
@JssDWt thanks for the logs. Yeah we need to clean the dust htlcs, will create a PR.
Background
Some sub dust apparently successfully forwarded htlcs are processed by the ChannelArbitrator indefinitely on every new block. Some of them are very old. A random one I found was from August 2021 for example and is being handled in every new block today.
We have some recent yet unexplained force closes where the logs surrounding the force close are swamped with 'go to chain for incoming htlc', which makes me think this behavior could cause other channels to close.
Here's logs from a single htlc that shows this behavior and is recent enough so I still have the initial forwarding log. As you can see it just keeps going forever. The channel is still open.
A possibly related log line around the time the HTLC was initially forwarded:
Here's the HTLC in the listchannels output:
Your environment
Steps to reproduce
I don't know
Expected behaviour
These htlcs should end up in a final state. Probably either by closing the channel, or by removing the htlc.
Actual behaviour
The htlcs are dangling forever. I don't know which is the oldest one, but at least one of them has expiration height 696312, which was August 2021.