chainntnfs: track remaining TxNotifier hint and lifetime fixes

Abierto
  • ¿Algo no está bien?
#11,248 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend

Línea de trabajo

Read the chainntnfs package, especially TxNotifier (set lifetimes, UpdateConfDetails/UpdateSpendDetails dispatch, CancelConf/CancelSpend) and the Neutrino GetUtxo progress path. The issue states most items are already fixed in PR #11183 (with a subset in #11247 and #11234), so first check those PRs before writing any code — done means the fixes land or an unclaimed item is verified unfixed. Expect the async state-machine model tests and CheckSetInvariants hook added there to define the expected behaviour.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

This issue tracks the chain notifier (chainntnfs.TxNotifier) bugs found while working on #11183 that aren't fixed by the minor release subset in #11247. That PR fixes the most severe class: missed historical confirmations and spends when duplicate subscriptions supply different height hints, including the restart case via persisted hint origins. Everything below exists on master today and is addressed in #11183 (targeting 0.22), except the last item.

Ranked roughly by severity:

  • Stale hint after the final cancellation. When the last subscriber for a request cancels, its cached hint is left behind with nothing maintaining it through reorgs. A reorg, then a restart, then a re-registration can skip a confirmation or spend on the replacement chain. Fixed in #11183 by releasing the hint to min(hint, tip - reorgSafetyLimit) on final cancellation, which no bounded reorg can invalidate.
  • Stale scan result credited to a recreated set. Results are reported via UpdateConfDetails/UpdateSpendDetails keyed only by request. If a set matures and is pruned while its historical scan is still outstanding, and a new registration recreates the set, the late result marks the new set complete and advances its hint past a range its own scan hasn't covered. Fixed in #11183 by having each dispatch carry its set and rejecting stale results with ErrStaleScanResult.
  • Neutrino spend progress goes stale on a reorg. Neutrino persists GetUtxo progress from the scan goroutine after every block. Pending sets aren't lowered when blocks are disconnected, so progress near the tip followed by a reorg and a restart can skip a spend. Progress could also claim past a spend the notifier had already found at tip. Fixed in #11183 by having the scan only record progress, which the notifier persists in updateHints under its lock, and only for a pending set that still has subscribers and hasn't learned of a spend.
  • Request sets leak. CancelConf/CancelSpend never remove a set, so every canceled registration whose event never matures stays in memory for the life of the process, along with details that fell out of the reorg index. Fixed in #11183: a subscriberless set is kept only while a scan is pending or its details are actually in the reorg index, plus reorg index guards so nothing is indexed at a height ConnectTip never prunes.
  • Failed historical rescans are never retried, and some are never reported. Tracked separately in #11234. Related: btcd never reports its outpoint and script spend rescans (results only arrive as relevant transactions), and neither does Neutrino's script spend rewind, so those dispatches leave a pending scan count behind. With the prefix scans in #11247, a btcd set that gets a prefix scan after its spend was reorged out can then stay in rescanPending until the spend is mined again, freezing its hint. Notifications are still delivered; the cost is a longer rescan on restart.

#11183 also adds the full async state machine model (cancellation, maturity, re-registration, Neutrino progress up to the tip) plus a CheckSetInvariants test hook for set lifetimes. The trimmed model in #11247 intentionally avoids those paths until the fixes above land.

Lenguaje dominante
Go
Estrellas
8.2k
Forks
2.3k
Merge medio
1 d 2 h
PR fusionados (30 d)
95

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de lightningnetwork/lnd

Todos los issues de lightningnetwork/lnd

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.