Expose LDK Node data currently dropped at the gRPC boundary

[Billa05]

Motivation

LDK Server currently drops several event variants and fields that are already exposed by its pinned LDK Node dependency. Exposing them would improve splice monitoring, payment diagnostics, channel observability, routing integrations, and on-chain accounting for all API clients.

This was audited against LDK Server 3e9e537 and its pinned LDK Node dependency 056447c.

Each item below is independently additive and may be implemented in separate PRs or a single PR.

Confirmed gaps

1. Splice lifecycle events

LDK Node emits two splice lifecycle events: SpliceNegotiated and SpliceNegotiationFailed.

SpliceNegotiated includes the fields:

• channel_id
• user_channel_id
• counterparty_node_id
• new_funding_txo

SpliceNegotiationFailed includes:

• channel_id
• user_channel_id
• counterparty_node_id

LDK Server currently handles both events through the catch-all event arm and immediately calls event_handled() without publishing an EventEnvelope.

Explicit protobuf event variants and mappings should be added for both events.

2. Payment failure reason

LDK Node's Event::PaymentFailed contains an optional PaymentFailureReason, which may be one of the following variants:

• RecipientRejected
• UserAbandoned
• RetriesExhausted
• PaymentExpired
• RouteNotFound
• UnexpectedError
• UnknownRequiredFeatures
• InvoiceRequestExpired
• InvoiceRequestRejected
• BlindedPathCreationFailed

LDK Server currently destructures PaymentFailed using .. and publishes only types.Payment.

An optional failure-reason enum should be added to the protobuf PaymentFailed event, with mappings for every current LDK variant.

This change would expose the reason only on the emitted event. GetPaymentDetails cannot recover it because LDK Node does not currently persist the failure reason in PaymentDetails.

3. Missing channel snapshot fields

LDK Node's public ChannelDetails already exposes several fields that are omitted from LDK Server's types.Channel, including:

• short_channel_id
• outbound_scid_alias
• inbound_scid_alias
• inbound_htlc_minimum_msat
• inbound_htlc_maximum_msat
• channel_shutdown_state
• reserve_type
• counterparty.features

These fields are useful for routing integrations, shutdown monitoring, reserve accounting, and distinguishing channel lifecycle state from temporary usability changes.

Corresponding protobuf fields should be added and populated in the ChannelDetails adapter.

4. On-chain transaction classification

LDK Node's PaymentKind::Onchain contains an optional TransactionType, but LDK Server currently discards it using ...

The classification distinguishes funding transactions, cooperative closes, unilateral closes, anchor bumps, claims, sweeps, and interactive funding/splice transactions. Several variants also contain associated channel IDs and counterparty node IDs.

This classification should be exposed in the protobuf on-chain payment type so it is returned by both GetPaymentDetails and ListPayments.

5. Additional dropped event and status fields

A few additional fields are also currently omitted:

• ChannelPending.former_temporary_channel_id
• PaymentSuccessful.bolt12_invoice
• NodeStatus.latest_pathfinding_scores_sync_timestamp

These could be added as optional protobuf fields.

Compatibility

All proposed changes are additive and should be backward compatible. This includes adding new EventEnvelope.oneof variants using unused field numbers, adding optional fields to existing messages, and introducing new enums or messages without modifying existing field numbers.

Existing clients should remain compatible.

Related work

Reliable, resumable event delivery is already tracked by #245. As an interim improvement, a lagged SubscribeEvents stream could terminate with gRPC DATA_LOSS instead of silently continuing.

The following items are intentionally excluded because LDK Node does not currently expose or persist the required data:

• pending_inbound_htlcs
• pending_outbound_htlcs
• next_splice_out_maximum_sat
• current_dust_exposure_msat
• Persisted payment failure reasons for GetPaymentDetails
• Modification-ordered payment reconciliation

[Billa05]

@benthecarman, could you please take a look when you have a chance? I’d appreciate your thoughts on the scope and whether these changes should be handled separately or grouped into one PR.