staticaddr: re-register on htlc tx conf error #1059
Conversation
Summary of ChangesHello @hieblmi, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the reliability of HTLC (Hashed Timelock Contract) transaction monitoring by introducing a re-registration process. Previously, an error during the initial HTLC confirmation registration could lead to the system failing to track the transaction, potentially missing critical sweep operations. The updated logic now attempts to re-establish monitoring upon encountering such an error, ensuring continuous and correct handling of HTLCs. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses an issue where an error on the HTLC transaction confirmation channel would cause the system to stop monitoring for the confirmation, potentially leading to failure in sweeping the HTLC timeout path. The proposed change correctly re-registers for confirmation notifications upon such an error. My review identifies a potential issue with the error handling of this re-registration. If the re-registration fails, the error is only logged, which could lead to a deadlock in the monitoring loop. I've provided a suggestion to propagate this error to the state machine for proper handling, which will make the implementation more robust.
hieblmi
force-pushed
the
reregister
branch
2 times, most recently
from
356dbfd to
c83bc3b
Compare
|
Thanks! 🏂 I added code coverage and a couple of related fixes here: hieblmi#3 PTAL |
staticaddr/loopin/actions.go
Outdated
| case err = <-invoiceErrChan: | ||
| f.Errorf("invoice subscription error: %v", err) | ||
|
|
||
| return f.HandleError(err) |
There was a problem hiding this comment.
This case occurs if the invoice deadline was reached and the invoice got cancelled. In this case we can't return here, but need to keep monitoring the htlc publication. So I am going to revert this line. @starius
There was a problem hiding this comment.
if the invoice subscription (not the invoice!) fails / cancels, we have to re-subscribe, otherwise we won't know that invoice was paid.
This is not critical so let's just add a TODO.
- propagate invoice subscription errors in MonitorInvoiceAndHtlcTx via HandleError instead of silently logging - add regression tests covering HTLC conf re-registration and invoice subscription error propagation
- reset htlcConfirmed when the HTLC conf subscription errors and we re-register - add regression test ensuring re-registers after a conf error require a fresh confirmation instead of sweeping on a stale one
3 participants
We need to re-register for htlc tx confs if the registration fires a conf error in
MonitorInvoiceAndHtlcTxAction. Otherwise we miss sweeping the htlc timeout-path.