staticaddr/loopin: make canceled-invoice timeout unlock recoverable

Đang mở
  • Có gì không ổn?
#1,167 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go
Lĩnh vực
backend, payments

Hướng nghiên cứu

Bắt đầu với MonitorInvoiceAndHtlcTxAction và transition MonitorInvoiceAndHtlcTx trên OnSwapTimedOut, sau đó kiểm tra UnlockState, OnRecover và unlockDeposits. Xem lại phần thảo luận về recovery và lifecycle trong PR #1161. Hoàn tất nghĩa là timeout không có xác nhận vẫn có thể recovery và chỉ đạt đến Failed sau khi các khoản tiền gửi được unlock hoặc đã biết là không cần thiết.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Problem

A static-address loop-in can reach the canceled-invoice recovery path without a durable guarantee that its deposits were unlocked.

Current monitor flow:

  1. the payment deadline path cancels the invoice and then unlocks deposits:

    cancelInvoice()
err = f.unlockDeposits(ctx)

  2. those are separate side effects. If loopd shuts down, crashes, or the deposit transition fails after invoice cancellation succeeds but before deposits are moved back to Deposited, recovery sees LookupInvoice return ContractCanceled;

  3. in that recovered state no new deadlineChan is created, so the deadline unlock path is not retried;

  4. if the HTLC never confirmed and the CLTV height arrives, MonitorInvoiceAndHtlcTxAction returns OnSwapTimedOut and the loop-in moves to Failed, while deposits may remain stuck in LoopingIn.

This was discussed during PR #1161: https://github.com/lightninglabs/loop/pull/1161#discussion_r3539797010

The issue appears to predate PR #1161, but that PR touched the surrounding recovery/lifecycle code and made the invariant visible.

Potential fix

Route the no-HTLC-confirmation timeout path through a recoverable state-machine unlock state instead of transitioning directly to Failed.

One possible shape:

  • add a success event such as OnDepositsUnlocked;
  • route MonitorInvoiceAndHtlcTx -> OnSwapTimedOut -> UnlockState (or a more specific UnlockDepositsBeforeFail state);
  • make UnlockState retry on OnRecover;
  • only transition UnlockState -> OnDepositsUnlocked -> Failed after unlockDeposits succeeds;
  • if unlockDeposits fails, keep the loop-in in the unlock state so restart/recovery retries cleanup rather than marking the swap failed with deposits possibly still locked.

The important invariant is: a no-confirmation timeout should not become final Failed until deposit unlock has succeeded or is known to be unnecessary.

Ngôn ngữ chính
Go
Star
594
Fork
137
Merge trung bình
2 ngày 8 giờ
Pull request đã merge (30 ngày)
15

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của lightninglabs/loop

Tất cả issue của lightninglabs/loop

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.