Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

withdraw: retry confirmation watching on failure and handle reorgs

Aperta
  • Qualcosa non va?
#1,087 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@kaldun-tech ci sta già lavorando.

Dal 12/4/2026.

  • #1129 di @kaldun-tech — chiusa senza merge
  • #1134 di @kaldun-tech — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go
Ambito
backend, blockchain

Direzione di ricerca

Inizia in staticaddr/withdraw/manager.go leggendo handleWithdrawal e il suo chiamante WithdrawDeposits, insieme ai percorsi RegisterConfirmationsNtfn e RegisterSpendNtfn. Segui il pattern esistente di nuovo tentativo al blocco successivo in altre parti della codebase e il flusso di persistenza dello stato Withdrawing. Il lavoro è completo quando le registrazioni fallite vengono ritentate, le conferme interessate da reorgs vengono gestite, i prelievi pubblicati restano recuperabili e pkScript viene passato dal chiamante.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
Go
Stelle
593
Fork
138
Merge medio
4g 18h
PR unite (30g)
20

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di lightninglabs/loop

Tutte le issue di lightninglabs/loop

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.