staticaddr/loopin: make canceled-invoice timeout unlock recoverable
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
MonitorInvoiceAndHtlcTxAction と OnSwapTimedOut における MonitorInvoiceAndHtlcTx transition から始め、続いて UnlockState、OnRecover、unlockDeposits を調べます。PR #1161 の recovery と lifecycle に関する議論を確認します。完了条件は、確認なしの timeout が引き続き recoverable であり、deposits の unlock が完了した後、または不要であることが判明した後にのみ Failed に到達することです。
索引モデルが issue の本文から書いたものです。
説明
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:
-
the payment deadline path cancels the invoice and then unlocks deposits:
cancelInvoice() err = f.unlockDeposits(ctx) -
those are separate side effects. If
loopdshuts down, crashes, or the deposit transition fails after invoice cancellation succeeds but before deposits are moved back toDeposited, recovery seesLookupInvoicereturnContractCanceled; -
in that recovered state no new
deadlineChanis created, so the deadline unlock path is not retried; -
if the HTLC never confirmed and the CLTV height arrives,
MonitorInvoiceAndHtlcTxActionreturnsOnSwapTimedOutand the loop-in moves toFailed, while deposits may remain stuck inLoopingIn.
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 specificUnlockDepositsBeforeFailstate); - make
UnlockStateretry onOnRecover; - only transition
UnlockState -> OnDepositsUnlocked -> FailedafterunlockDepositssucceeds; - if
unlockDepositsfails, 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.
- 主要言語
- Go
- スター
- 593
- フォーク
- 138
- 平均マージ
- 4日 18時間
- マージ済み PR（30日）
- 20
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
lightninglabs/loop のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
lightninglabs/loop#1246 ·
メンテナーはふだん 2 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 50/100
lightninglabs/loop#1208 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
lightninglabs/loop#1196 ·
メンテナーはふだん 2 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 42/100
lightninglabs/loop#1172 ·
メンテナーはふだん 2 日以内に返信
-
Track armed static address HTLCs after aborted swaps再び着手できるかも @hieblmi が 107 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
lightninglabs/loop#1171 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
lightninglabs/loop の issue をすべて見る
似ている issue
-
Project submission:オープン
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
slavakurilyak/awesome-ai-agents#845 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 3 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
JakeChampion/lang#13132 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] deploy.restart_policy without condition drops the restart policy対応中かも @akshat-lakhera が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
docker/compose#14383 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信