Handle outbound terminal LDK events when the payment record is missing

[joostjager]

Problem

src/event.rs, EventHandler::handle_event, handles outbound terminal LDK events by updating PaymentStore and then queueing a user-facing app event. However, the current match accepts DataStoreUpdateResult::NotFound as success because it matches Ok(_).

For LdkEvent::PaymentSent:

1. The handler builds a PaymentDetailsUpdate with the payment hash, preimage, fee, and PaymentStatus::Succeeded.
2. It calls self.payment_store.update(update).await.
3. The match arm is Ok(_) => {}, so NotFound is treated the same as Updated or Unchanged.
4. It optionally calls self.payment_store.get(&payment_id) only for logging.
5. It queues Event::PaymentSuccessful with self.event_queue.add_event(event).await.

For LdkEvent::PaymentFailed, the same pattern applies: it builds a failed update, calls self.payment_store.update(update).await, treats Ok(_) as success, and then queues Event::PaymentFailed.

The underlying DataStore::update in src/data_store.rs explicitly returns Ok(DataStoreUpdateResult::NotFound) when the object is missing. That result does not create or persist a new record.

This also matters for future duplicate protection. In src/payment/bolt11.rs, Bolt11Payment::send_internal checks self.payment_store.get(&payment_id) before calling LDK, and known_payment_blocks_send only blocks a send when the local record is Pending or Succeeded. If a successful outbound terminal event is emitted without reconstructing a missing Succeeded record, ldk-node's duplicate gate may later have no durable record proving that the invoice or payment hash was already paid.

Consequence

An application can receive PaymentSuccessful or PaymentFailed while Node::payment and Node::list_payments still have no corresponding payment record. For success, this can look like sats were spent with no durable ldk-node payment history. It can also weaken duplicate-payment protection: if LDK no longer tracks the payment in recent payment state and ldk-node has no Succeeded record, ldk-node may not block a later attempt to pay the same invoice or payment hash before handing it to LDK. For failure, retry behavior becomes harder to reason about because the terminal state was emitted as an event but not recorded in the payment store.

[IgnacioPorte]

Happy to take a look at this if no one's already on it.

The small fix seems clear enough: in the PaymentSent and PaymentFailed arms, match the update result explicitly instead of Ok(_) => {} and handle NotFound on its own. That means logging it and still emitting the user-facing event (the payment did resolve), but without ReplayEvent(), since a replay won't recover a missing record. It would bring these arms in line with what the inbound PaymentClaimed arm already does.

On rebuilding the missing record, the two arms turn out quite different around recovering the PaymentKind:

• PaymentSent: the kind looks recoverable. bolt12_invoice gives us the Bolt12 cases, and the only leftover ambiguity is Bolt11 vs Spontaneous, which seems harmless since the record is identical apart from the label. amount_msat is on the event too, just dropped via .. today.
• PaymentFailed: not really recoverable. No bolt12_invoice and no amount, and the only signal (payment_id vs payment_hash) leans on id convention, so it feels too fragile to rely on.

A few ways this could be scoped:

• Purely defensive in both arms (handle NotFound, no reconstruction).
• Reconstruct on PaymentSent (Bolt12 precisely, default the Bolt11/Spontaneous case) and keep PaymentFailed defensive-only.
• Reconstruct in both arms, accepting a lossy/kindless record on PaymentFailed.

There's also #969, which feels like a separate concern to me since it's a startup reconciliation pass rather than event handling, but it overlaps here and might affect how much belongs in this issue. Let me know what you think.

[joostjager]

The reconstruction feels quite hacky to me. It would be great if we can somehow address the root cause of the missing record. @tnull what are your thoughts on the fix direction?