-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug]: Channels Stuck in "Waiting to Close" State Despite Confirmed Transactions #9532
Comments
Does your wallet show as being synced? Is your chain backend a pruned node? |
Wallet seems to be synced as I was able to open other channels while this was happening. Backend is full bitcoind node. What type of error would I be looking for so I can search the logs? I do suspect that a reset may fix the issue just trying to exhaust other possible options to avoid the lengthy downtime. Also would love to discover why this happened, and if it was preventable. |
Can you just grep by |
You may want to change the config values for the budget, since some of the HTLCs have already reached their deadlines, by default half of their value will be used as fees when they are swept, Lines 1834 to 1872 in 27440e8
|
Can you try disabling the height_hint cache and check if the closing transactions resolve ? in the lnd.conf |
Thanks I will try this and report back. |
@guggero Ok will do with the next restart, and send you some output. |
@yyforyongyu are you suggesting I increase the ratio? I am not sure that the issue is related to the economical sweeping seems a lot of the pending sweeps have been broadcasted and confirmed but not updated. |
@jjacks95 is the bitciond node running with a txindex activated? |
@Roasbeef Yes it is |
Thanks for the logs. So I see a lot of these errors:
In addition with the fact that there are a lot of pending queries for the |
Description:
Our LND node is encountering an issue where channels remain in the "Waiting to Close" state even though the associated close transactions have been successfully confirmed and broadcasted on the blockchain.
Observed Behavior:
Rebroadcasting Confirmed Transactions:
The node continuously attempts to rebroadcast transactions that have already been successfully broadcasted and confirmed. This behavior is redundant and may indicate an internal state mismatch.
Pending Sweeps Incorrectly Displayed:
The "Pending Sweeps" section lists transactions as pending even when they are fully confirmed on the mempool. This discrepancy suggests that LND is not correctly updating its internal state or transaction status.
Channels Stuck in "Waiting to Close" State:
Channels that have been closed with confirmed transactions remain listed as "Waiting to Close". This state should be updated automatically once the closure is confirmed, but the node does not reflect this. Not sure what is causing as these dont even transition into the pending force closure state.
Database Query Overload at Startup:
Each startup triggers an excessive number of PostgreSQL queries, leading to a bottleneck. Many queries get stuck, and if not manually terminated, they eventually cause the node to crash.
Expected Behavior:
Additional Information:
This issue significantly impacts node stability and operational reliability, particularly during restarts or when managing channel closures. Any insights or guidance on addressing this behavior would be greatly appreciated. I am unsure what I am looking for in the logs to explain the behaviour so if there is more I can provide just let me know.
Also I know that there is usually a 2 week window of delay for force closures, I am mostly concerned with the fact that these channels have not moved into a forced closure state displaying the
maturity_height
andblocks_til_maturity
. As well hoping to understand why confirmed transactions would still appear inwallet pendingsweeps
.PSQL Example
PSQL Example
Pending Channels Output
Pending Sweeps Output
Log
The text was updated successfully, but these errors were encountered: