You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Model pending payments as an enum for pre-broadcast splices
Retrying a user-initiated splice across restarts requires persisting the
splice intent before handing it to LDK, which happens before negotiation
and therefore before any funding transaction exists. The pending-payment
record was built around an on-chain PaymentDetails carrying a txid, which
cannot represent a splice that has not been broadcast yet.
Reshape PendingPaymentDetails into an enum: a PendingSplice variant that
holds only the generated PaymentId and the splice intent, and a Tracked
variant that is the previous record plus an optional intent retained until
the splice locks. Add the SpliceIntent and SpliceKind types the intent
needs to resubmit or rebuild the contribution.
Wallet writes to the pending store go through a new DataStore::mutate
primitive that reads, transforms, and persists an entry under one critical
section of the mutation lock, replacing racy read-then-write pairs. The
wallet's pending-store writes share one helper whose closure promotes a
bare PendingSplice to a Tracked record once a payment exists under its id:
a plain payment-tracking merge would silently no-op against the variant,
leaving the splice invisible to txid lookups.
This is groundwork; nothing constructs a PendingSplice yet. The classify,
retry, and wiring that use it follow in subsequent commits.
Generated with assistance from Claude Code.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
0 commit comments