-
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 |
Hi @jjacks95 has there been any update on this issue from your end, after incorporating the suggestion made so far? |
@saubyk I couldn’t pinpoint the exact cause, but using --reset-wallet-transactions resolved the transaction issues. It seems possible that what @guggero mentioned earlier could have contributed to the problem, but I’m not sure how to confirm that. None of the other suggestions helped fix the problem although maybe they will help prevent future ones, but it seems that once the transactions were incorrectly tracked, a reset was the only solution. I still have some channel closures pending force and waiting to close. I’m not entirely sure what causes channels to get stuck in this state or how long they might remain there. The reset did seem to fix the pending sweeps issue—swept transactions are now gone, and only those with a future deadline height remain. I’m keeping an eye on them, but I’ve read it can take up to two weeks for this to fully resolve. Anyway I am happy to try other suggestions, although at this point I do think all is running ok given the info in the wallet is matching what I expect. I will wait to see after 2 weeks if these channels have been removed and the pending sweeps are no longer pending post deadline. |
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: