LOL I just got done asking my AI if the new code I've written to pay invoices (which is 100x better than the old code) had anything wrong with it...

Your implementation of send_lightning_to_pay_req is generally correct and follows the LND gRPC interface as intended. You are:

• Building the SendPaymentRequest with all required fields.
• Handling zero-value invoices.
• Logging and raising exceptions for various error cases.
• Parsing and validating the payment response.

However, here are a few suggestions and observations for improvement or clarification:

1. Failure Reason Handling:

• You only raise an LNDPaymentError with the failure_reason if payment.status == "FAILED", but you do not map or log the specific LND failure reason (e.g., FAILURE_REASON_INCORRECT_PAYMENT_DETAILS, FAILURE_REASON_UNSET) in a user-friendly way. Consider mapping these to more actionable messages or logging them more explicitly.

1. Payment Status Loop:

• You process all responses from SendPaymentV2, but only the last payment_dict is used for validation. This is correct for most cases, but if you want to capture intermediate states or partial failures, you might want to log or aggregate them.

1. Exception Handling:

• You handle AioRpcError and generic Exception, which is good. However, you could consider parsing e.code() for more granular gRPC error handling if needed.

1. Fee Limit Calculation:

• You ensure fee_limit_msat is never zero, which is correct. The logic for self-payment is hardcoded to a specific channel; a TODO is present, so just be aware this may need to be dynamic in the future.

1. Logging:

• Your logging is thorough, but you might want to include the payment_hash or payment_id in all logs for easier tracing.

1. Zero-Value Invoice Amount:

• You correctly check and raise if amount_msat is zero for zero-value invoices.

1. Custom Records:

• You are setting custom records as needed for your app.

Summary:
You are not doing anything fundamentally wrong. The function is robust and follows LND’s gRPC expectations. The main area for improvement is to make the failure_reason handling more explicit and user-friendly, especially for common LND failure reasons, and to ensure all logs include enough identifiers for tracing.

If you want, I can suggest a patch to improve the failure reason mapping and logging. Would you like that?