Repository navigation
Conversation
Update LDK Node's Cargo.toml to use recurrence-aware versions of rust-lightning and bitcoin-payment-instructions. This makes the recurrence APIs available for implementing recurrence support in subsequent commits. Co-authored-by: GLaDOS
Recurring offers outlive individual payment attempts and node processes. To resume a recurrence safely after restart, the node must retain its original offer terms, lifecycle state, payment progress, and payee-provided opaque state. Add RecurrenceDetails and RecurrenceStatus with TLV serialization and RecurrenceId-based persistence. Load recurrence records during node construction under a dedicated "recurrences" namespace, retaining all entries for the lifetime of each recurrence. Thread RecurrenceStore through Node, EventHandler, and Bolt12Payment to establish the persistence foundation for recurrence scheduling and payment handling. Recurring payment execution remains disabled in this commit. Co-Authored-By: GLaDOS
Add an API to start an outbound recurrence by submitting its initial invoice request. Validate quantity against the offer and calculate its minimum total with checked multiplication. Reserve the recurrence and initial payment before submission, rejecting existing IDs rather than overwriting their records. Retain submission failures without advancing paid progress. Failure updates only affect the reserved attempt and preserve completed payments. Acquire recurrence-store locks before payment-store locks. Co-Authored-By: GLaDOS
|
👋 Hi! I see this is a draft PR. |
5 of 7 tasks
Allow callers to submit subsequent payments using the stored recurring offer and payment parameters. Require an active recurrence, a successful initial payment, no active attempt and an open payment window. Validate the next period against the inclusive recurrence limit. After submission, persist the payment record and associate its ID with the recurrence for event handling. Return the payment ID on successful submission and an error on synchronous failure. Submission failures other than duplicate payment IDs are recorded as failed payments, while the recurrence attempt is marked active. Co-Authored-By: GLaDOS
Failed initial payments cannot be retried through pay_next_outbound_recurrence, which requires the first payment to have succeeded. Add retry_outbound_recurrence for active recurrences with a failed attempt. Reuse reservation and submission without advancing the recurrence period. Validate the payment window before reservation and again before queueing, including initial retries with an explicit basetime. Permit an unknown window only when the first payment has not established basetime and the offer does not specify one. Co-Authored-By: GLaDOS
Recurring payments need persisted outcomes so callers can determine whether to retry an attempt or pay the next period after restart. On success, retain the payment ID, advance paid progress, establish the basetime, and save the payee's opaque state for the next request. Clear the active attempt and mark the recurrence completed when its limit is reached. On failure, retain the failed payment ID without advancing paid progress. Match outcomes to the active payment ID and recheck ownership under the mutation lock so replayed events cannot overwrite a newer attempt. Request event replay when persistence fails. Co-Authored-By: GLaDOS
Cancel an outbound recurrence locally and queue a cancellation request for the payee after a successful payment. Use the same mutation lock as submission so cancellation can prevent an unqueued reservation from being submitted. Abandon an active attempt while retaining its payment ID for late success or failure handling. Read the latest recurrence state under the lock rather than overwriting progress from an earlier snapshot. Persist local cancellation even when remote cancellation queueing fails, then return the queueing error. Co-Authored-By: GLaDOS
shaavan
force-pushed
the
outbound-recurrence
branch
from
October 26, 2026 14:26
4370382 to
75c10ae
Compare
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This PR adds payer-side tracking and manual payment APIs for recurring BOLT 12 offers in LDK Node, based on lightning/bolts#1240.
rust-lightning handles the recurrence protocol and invoice requests. LDK Node persists each recurring relationship, validates payment parameters and windows, reserves attempts before submission, and records payment outcomes.
Applications can initiate a recurrence, pay its next period, retry a failed attempt, cancel it, and inspect saved progress.
Scope
Deferred work
Deferred work
The following work is deferred to follow-up PRs.