Skip to content

boarding sweep: revisit finality-gated durable confirm in the reorg redesign #985

Description

@Roasbeef

Since the reorg-aware txconfirm lifecycle landed, a TxConfirmed
delivery is provisional and the boarding-sweep durable bookkeeping (the
boarding_sweeps row flipping to confirmed, the ledger fee entry, and
the in-memory watch teardown) only commits on TxFinalized, which the
chain backends synthesize at chainsource.DefaultFinalityDepth = 6
inclusive confirmations.

To be clear about the blast radius: nothing operational gates on that
status. The sweep broadcasts immediately, the swept coins are ordinary
wallet UTXOs spendable under the wallet's own confirmation policy, and
the only consumer of the confirmed status is
isTerminalSuccessSweepStatus (the guard that stops a spurious late
TxFailed from rolling back already-booked accounting). What users see
is purely observability lag: ListBoardingSweeps reports published
for ~an hour on mainnet before flipping, and the ledger fee entry books
equally late. Downstream test suites also need to know about the
horizon — the lumos itests had to bump their post-broadcast mining from
3 to 6 blocks so the terminal status becomes observable at all
(lightninglabs/lumos#680).

For the upcoming reorg PR series: consider whether the durable
bookkeeping should instead commit on first confirmation and repair on
TxReorged (act-then-repair), rather than waiting out the full
reorg-safety horizon (wait-then-act). The general design lean elsewhere
in the daemon is to take the next action as soon as a confirmation
lands and treat reorgs as the exceptional path to recover from; the
sweep bookkeeping is currently the odd one out. If wait-then-act stays,
the finality depth should probably become configurable (regtest/test
rigs want 1-2) and the RPC could surface a distinct finalizing state
so the long published window doesn't read as a stuck sweep.

Related surfaces already reconciled to the lifecycle in #972: the
unroll subscriber maps TxFinalized to an idempotent confirmation
(it used to terminally fail the job) and drops best-effort TxReorged;
the wallet's log-only sweep subscriber treats finality as a repeat
confirmation. Whatever shape the redesign picks, those adapters and the
boarding-sweep classifier should move together.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions