Inconsistent status and recovery for loops with double payment
Maintainer thường phản hồi trong vòng 7 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
- 35/100
Hướng nghiên cứu
Bắt đầu bằng cách kiểm tra việc xử lý khôi phục loop cho hai trường hợp đã được báo cáo: một swap FAILED đã được khôi phục thông qua giao dịch timeout và một swap SUCCESS không khôi phục được khoản thanh toán kép. So sánh hành vi giữa các lần khởi động lại loop và với chantools recoverloopin; được xem là hoàn tất khi việc khôi phục được thử đúng vào lúc cần thiết và không được lặp lại sau khi tiền đã được khôi phục.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
We did two swaps where we paid twice (one manually and one automatically done by loop itself). Both swaps actually went through successfully.
One of the swaps had trouble finishing to SUCCESS status, and eventually reached FAILED status (reason FAILURE_REASON_TEMPORARY). That swap has actually recovered the funds from the double pay through a timeout tx. Also, even though the swap is FAILED and already recovered the double pay, it's still trying to send more recovery transactions every time we restart loop.
The other swap has SUCCESS status but never tried recovering the funds. We eventually had to recover the funds with "chantools recoverloopin". That swap seems settled by loop since it's not trying to recover the double pay.
Let us know if you need more logs or other information from the servers.
PS: Also to avoid this issue, maybe when creating a loop it should say clearly when it's going to be paid by loop, and when it requires external funding, since we got confused by this :)
- Ngôn ngữ chính
- Go
- Star
- 593
- Fork
- 138
- Merge trung bình
- 4 ngày 9 giờ
- Pull request đã merge (30 ngày)
- 14
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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của lightninglabs/loop
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
lightninglabs/loop#1246 ·
Maintainer thường phản hồi trong vòng 7 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 50/100
lightninglabs/loop#1208 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 7 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
lightninglabs/loop#1196 ·
Maintainer thường phản hồi trong vòng 7 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 42/100
lightninglabs/loop#1172 ·
Maintainer thường phản hồi trong vòng 7 ngày
-
Track armed static address HTLCs after aborted swapsCó thể làm lại được @hieblmi đã nhận 106 ngày trước và không có pull request nào đang mở. Đang mở
lightninglabs/loop#1171 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 7 ngày
Tất cả issue của lightninglabs/loop
Issue tương tự
-
compress: block buffers get re-zeroed on every call, and the zeroing is immediately overwrittenĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
ClickHouse/ch-go#1218 ·
Maintainer thường phản hồi trong vòng 13 ngày
-
effort:s impact:low raised-by:reviewer risk:low
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 84/100
medici-finance/assay#4251 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
automation models
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
golang-migrate/migrate#1457 ·
-
Make --data-dir a required flagĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 1 ngày