LND

This change threads a request context through the DeletePayment database operation. In practical terms, it lets the database operation respect cancellation or timeout signals from the original RPC request, rather than running with a blank 'do nothing' context. The SQL backend now uses the real request context, while the older key-value backend still ignores it for now. This is a code-quality and robustness improvement, not a fix for an active security vulnerability.

This commit only adds a single line to the release notes document, describing a completed code change (finalizing SQL payments implementation and enabling tests). It does not modify any program code, configuration, or security mechanism.

This commit is a straightforward internal refactoring: it adds a context.Context parameter to the FetchPayment function and threads it through callers. Contexts allow operations to be cancelled or timed out, but the commit does not change any behavior, fix a bug, or close a security hole. It is not a security patch.

This commit only adds explanatory comments to two source files. No code behavior is changed, so it cannot introduce or fix a security vulnerability on its own.

This commit removes one blank line in a test file to satisfy a code linter. It does not change any program logic, behavior, or security-relevant code.

This commit only adds new automated tests for an existing database method called FetchInFlightPayments. It does not change any production code, so it cannot introduce or fix a security vulnerability on its own.

This commit only updates a unit test file to include sample custom records when creating test payment data. It does not change any production code, network behavior, or security logic. There is no security issue here.

This commit only adds a Go build tag to a test file so that certain key-value store tests run only when neither SQLite nor PostgreSQL test modes are active. It is a test-configuration change with no effect on production code, user-facing behavior, or security.

This commit only changes an integration test file. It adjusts how timestamps are rounded when testing the ListPayments and ListInvoices features, so the tests pass reliably across different database backends. There is no change to production code, no security fix, and no vulnerability being patched.

This commit only reorganizes test code for the payments database. It introduces a small test helper interface so the same unit tests can run against both the older key-value (KV/Bolt) backend and the newer SQL backend. No production code is changed, and nothing about how real user payments are handled is modified.

This is a test-only adjustment that updates a fake payment route used in unit tests so it matches the new real-world behavior of LND: legacy onion payloads are no longer supported, only modern TLV-encoded payloads. It also adds a code comment and a TODO about eventually removing the now-deprecated LegacyPayload field. There is no runtime security fix here.

This commit only moves and refactors test code. It makes an existing payment-querying test work with any database backend and keeps the legacy key-value (KV) store duplicate-payment test separate. No production code was changed, so there is no security risk or fix here.

This commit only adds test helper code for the payments database. It introduces build-tag-guarded test files that let the same payment database tests run against either the existing key-value backend, a SQLite backend, or a PostgreSQL backend. There is no change to production code, user-facing behavior, or security-sensitive logic.

This commit removes a leftover placeholder that made a new SQL-based payment database fall back to an older key-value store while its own methods were still being written. Now that all required methods are implemented, the fallback is no longer needed. There is no security issue here—this is a normal cleanup of completed refactoring work.

This commit only changes test helper functions in the payments database test files. It refactors how fake payment data is generated so each simulated payment attempt uses a different cryptographic session key, matching a stricter SQL backend. There are no changes to production code, user-facing behavior, or security-sensitive logic.

This commit only renames internal functions and variables in a single database file to make the naming style consistent with another part of the project. No behavior, logic, or security properties of the code are changed.

This commit only adds a single line to the release notes document, pointing to a previous code change (pull request 10368) that implemented SQL backend payment functions. There are no code changes, no bug fixes, and no security-related content in the diff itself.

This commit only adds a new unit test file for an existing internal function. It does not change any production code, fix a bug, or alter behavior. There is no security issue here.

This commit adds a missing database method for the new SQL backend in LND. It lets the node efficiently find all payments that still have HTLC attempts in flight during startup. There is no security fix here; it is a feature/performance parity change to match the older key-value store backend.

This commit adds a new database cleanup feature to LND's SQL payment storage backend. It lets the node delete old payment records or failed payment attempts in bulk. The change is mostly a feature implementation and refactoring; there is no direct evidence in the commit that it fixes an active security vulnerability. The main security-relevant aspect is that the code deliberately skips payments that are still 'in flight' (active on the Lightning network) and only removes payments whose status is considered 'removable', which reduces the risk of deleting data needed for an ongoing payment.

This commit is a routine internal refactoring of how the LND payment database fetches HTLC resolution data. It replaces a single large SQL query with a helper that breaks the work into smaller batches. There is no indication this fixes a security bug; it appears to be a performance and maintainability improvement.

This commit refactors how LND's payment database looks up payments. It introduces a shared helper that converts a 'no rows found' database result into a specific, expected error (ErrPaymentNotInitiated). Several existing functions are switched to use this helper, and a few places that previously wrapped the raw database error with extra text now return the error directly. The change is mostly a cleanup, but it also tightens error handling so missing payments are treated consistently rather than as unexpected database failures.

This commit is a simple internal code rename with no functional changes. A data structure called paymentsBatchData is renamed to paymentsDetailsData, and all references to it are updated. The commit also adds a clarifying comment explaining what the structure holds. No security issue is present.

This commit only adds a single line to the release notes document, mentioning that insert methods were implemented for a payments database SQL backend feature. It contains no code changes, no bug fixes, and no security-related content.

This commit adds a missing database method called FailAttempt for the new SQL backend in LND's payment database. It simply records when an individual payment attempt (HTLC) fails, including the reason and timestamp. There is no security vulnerability visible in the change; it is a normal feature-completion patch that brings the SQL backend in line with the existing KV backend.