Add PaymentMetadataStore for Bolt11 and Bolt12 inbound payments #537
Conversation
…allback - Add PaymentMetadata to represent metadata for inbound payments - Add PaymentMetadataStore for persisting PaymentMetadata - Add PaymentDataWithFallback to handle backward compatibility during the transition from legacy bolt11/bolt12 pending payments to the new PaymentMetadata format Issue lightningdevkit#425
Introduces the optional `legacy_payment_store` feature to enable testing of legacy payment flows during the transition to `PaymentMetadata` for inbound payments. Issue lightningdevkit#425
…g paymentStore Inbound Bolt11 and Bolt12 payments that are pending should now be stored in `PaymentMetadataStore` rather than directly in `PaymentStore`. Once the payment is completed (successful or failed), it is then moved to `PaymentStore`, and its status is updated in `PaymentMetadata`. This change maintains backward compatibility with the previous behavior of storing all payment information directly in `PaymentStore`. issue lightningdevkit#425
…cy behavior The test was modified to be compatible with the new `PaymentMetadata` logic, while still verifying compatibility with the legacy rule that stores payments directly in `PaymentStore`. Issue lightningdevkit#425
|
I've assigned @jkczyz as a reviewer! |
Excuse the delay here. As noted over at #425 (comment), I think there are some misconceptions about what the payment metadata store is meant to be here. Unfortunately I think this PR is headed in the wrong direction as is. I'm going to close this PR for now, but feel free to reopen once we synced on the approach and are aligned on what approach should be taken. |
This PR introduces
PaymentMetadatato handle inbound Bolt11 and Bolt12 payments more consistently.Summary of changes:
PaymentMetadataandPaymentMetadataStoreto persist metadata for incoming payments.PaymentDataWithFallback, a structure that contains bothPaymentMetadataandPaymentDetailas Options, along with shared fields like payment status and direction. This helps ensure backward compatibility.PaymentMetadataStoreinstead ofPaymentStore.PaymentStoreonce they are completed (either successfully or failed)when payments are pending they are in thePaymentMetadataStore. Also ensures compatibility with legacy behavior, where payments were stored exclusively inPaymentStore.legacy_payment_storeCargo feature to test legacy behavior and validate backward compatibility.legacy_payment_storefeature in the CI workflow to ensure everything works as expected.Ref: #425