fix ChannelPending Panic#112
Conversation
|
I cannot consider the test valid since it's doing a manual hack (setting |
194b12c to
446729c
Compare
|
On my side the new test is failing. Here the logs: |
a49204f to
45b4ae7
Compare
|
The test is now passing, let me know if we can auto-release the lock if has been locked for more than 30 secs, or we should use another approach |
|
No, auto-releasing the lock is not safe. We need to find where it needs to be set to false. Is the analysis reported in #111 correct? Is a panic actually happening during the |
|
Yes #111 analysis is correct |
|
I tried the test without the "fix" and I don't see any panic. What panic do you see? |
1725cb9 to
0fd5b66
Compare
|
Reworked the PR based on your feedback: Removed the 30s auto-release timeout Regarding the panic question — the lock gets stuck even without a panic. The issue is that |
|
I tried the test without the fix but it passes, we need a bug to be proven before thinking about the fix About
the reasoning here has some issues. The lock should be released after calling the send end method. Before that it can be released only if errors arise. |
Open a vanilla channel from node1 to node2, shut down node2 before the funding TX is mined (ChannelPending never fires), then verify that node1 cannot open a new channel to node3 because rgb_send_lock is never released. The ChannelClosed event handler does not reset rgb_send_lock, leaving the node permanently unable to open new channels. Ref: RGB-Tools#111
0fd5b66 to
731bceb
Compare
|
on my env the test is failing but i saw on the pipeline is not. i will close this PR and reopening it, if I'll find a way to replicate the issue |
reproduce and fix #111