Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

withdraw: retry confirmation watching on failure and handle reorgs

オープン
  • 何か問題がありますか？
#1,087 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@kaldun-tech がすでに取り組んでいます。

2026年4月12日 から。

  • #1129 @kaldun-tech による — マージされずにクローズ
  • #1134 @kaldun-tech による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
go
領域
backend, blockchain

調査の方向性

staticaddr/withdraw/manager.go から始め、handleWithdrawal とその呼び出し元である WithdrawDeposits、および RegisterConfirmationsNtfn と RegisterSpendNtfn の経路を読みます。コードベースの他の場所にある次のブロックで再試行する既存のパターンと、Withdrawing 状態の永続化フローを追跡します。失敗した登録が再試行され、reorgs で影響を受けた confirmations が処理され、公開済みの withdrawals が復旧可能なままとなり、pkScript が呼び出し元から渡されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Context

From PR #1078 review, @starius identified two improvements needed for the withdrawal confirmation watching code in staticaddr/withdraw/manager.go.

Current Behavior

In handleWithdrawal, when RegisterConfirmationsNtfn or RegisterSpendNtfn fails, the error is logged and the goroutine returns. There is no retry mechanism, so the withdrawal may never be detected as confirmed.

Additionally, if a withdrawal transaction receives one confirmation but is then reorged out, the current code does not handle this situation — the withdrawal stays in a confirmed state despite no longer being in the chain.

Issue 2: State persistence failure on handleWithdrawal error

From PR #1078 review, @starius identified a related issue in the same code path:

If handleWithdrawal fails (because GetStaticAddressParameters or RegisterSpendNtfn fails), the caller (WithdrawDeposits) returns the error without updating internal state or persisting the state change to Withdrawing. This is a correctness/state-tracking failure — the withdrawal tx may already be published, but the restart recovery path won't pick it up because recovery sources on Withdrawing deposits.

Recommended fix shape:

  1. After publish success, immediately persist/transition the withdrawal state (FinalizedWithdrawalTx, finalizedWithdrawalTxns, Withdrawing, DB update) before calling handleWithdrawal.
  2. Start handleWithdrawal as best-effort; if it fails, log + schedule retry, but do not return a user-facing error for an already-published tx.

Secondary improvement to handleWithdrawal itself:

  1. Stop fetching address params inside handleWithdrawal; pass the required pkScript from the caller.
  2. The pkScript (of the static address) can be calculated upfront, even before publishing, at the very beginning of FSM operation.

Proposed Changes

  1. Retry on next block: If Register* calls fail, retry at the next block detection instead of giving up. This retry-on-next-block pattern is already used in other parts of the codebase.

  2. Handle reorgs: If a withdrawal tx gets confirmed but is later reorged out, detect and handle this automatically (e.g., re-register for spend/confirmation notifications).

  3. Decouple state persistence from handleWithdrawal: Persist the Withdrawing state transition immediately after successful tx publish, so that restart recovery works even if handleWithdrawal subsequently fails.

  4. Pass pkScript from caller: Remove GetStaticAddressParameters call from handleWithdrawal and pass the pkScript in from the caller, where it can be computed once upfront.

References

  • File: staticaddr/withdraw/manager.go, around the handleWithdrawal function
  • PR: #1078
主要言語
Go
スター
593
フォーク
138
平均マージ
4日 18時間
マージ済み PR（30日）
20

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

lightninglabs/loop のほかの issue

lightninglabs/loop の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。