LND

This commit fixes a bug in a test helper that runs database transactions for LND's graph database migration tests. The old code accidentally committed every transaction, even when the inner test work failed, because of a subtle Go error-handling mistake. The fix makes failed transactions roll back and successful ones commit properly. This is test-only code, so it does not directly affect live Lightning nodes, but it could have caused migration tests to leave partial or incorrect data in the database instead of rolling back as intended.

This commit adds a new automated test that checks whether database migration files are correctly named, uniquely numbered, and match the project's internal migration list. It does not change any production code or fix a live bug; it only adds a safety check to catch human errors during future development.

This commit is a straightforward internal code cleanup in LND's payment database code. It splits migration-only database query methods out of the general SQLQueries interface into a new SQLMigrationQueries interface. There is no security bug being fixed here; it is a refactoring change to make the codebase clearer and prevent accidental use of migration-only queries in normal operation.

This commit is a routine Go module housekeeping change. It removes the '// indirect' label from a tiny helper library (go-difflib) so Go recognizes it as a direct dependency. There is no code change, no bug fix, and no security-relevant behavior change visible in the diff.

This commit only adds a new developer test file and a README for manually debugging database migrations. The test is skipped by default and requires a developer to edit the code and supply their own database file before it will run. There is no change to production code, no fix for a security issue, and no new vulnerability introduced.

This commit only adds new test code and test helpers for an existing database migration. It does not change any production logic, runtime behavior, or user-facing functionality. There is no security issue in the commit itself.

This commit fixes a database migration bug in LND's payment storage upgrade. Older Lightning payments sometimes didn't store a payment hash on each individual HTLC (payment attempt). The migration to a new SQL database previously failed when it encountered these legacy records. The fix simply falls back to the parent payment's hash, matching how the rest of LND already treats legacy payments. This is a reliability fix, not an exploitable security vulnerability.

This commit wires a new experimental database migration into LND that moves payment data from an older key-value store to a newer SQL-based store. It also adds a 'tombstone' marker so that, once the migration runs, the old key-value store cannot be used again. The change is only active when a special test build tag is used, so it does not affect normal production builds. There is no direct security vulnerability visible in the diff, but any database migration carries operational risks such as data loss or being unable to restart the node if something goes wrong.

This commit is a defensive code-freeze: it copies the core payment database logic into a dedicated migration1 package so that future changes to the main payments code or serialization format cannot accidentally break or corrupt old payment data during upgrades. It is a hardening/refactoring change, not an active vulnerability fix, and it reduces the risk of migration bugs rather than introducing new exploit paths.

This commit adds a new database table called payment_duplicates to help migrate old LND payment records into a new SQL database. Older versions of LND could accidentally create multiple payments with the same identifier, which conflicts with the new database's rule that each payment hash must be unique. The new table stores the extra duplicate records separately during migration so no data is lost. It is not a security fix and does not change how live payments are handled; it only preserves historical records.

This commit adds new code that migrates old-style payment records into a new SQL database format and checks that the migrated data matches the original. It is a data-integrity migration, not a typical security patch. The code does not obviously introduce remote attacks, but it changes how sensitive payment history is stored and interpreted. Any bug here could corrupt payment state, misclassify failed payments as successful (or vice versa), or lose duplicate-payment records. The commit itself does not claim to fix a security vulnerability.

This commit adds two database helper functions used only during a one-time upgrade from the old key-value storage to the new SQL database in LND. One helper lets the migration insert old payments that already have a failure reason, and the other fetches batches of payments with their attempt counts for validation. There is no user-facing change, no bug fix, and no security patch in the diff itself.

This commit is a minor cleanup in LND's payment database code. It removes a duplicate compile-time type check and reorders two table-drop statements in a database downgrade script. The author notes the reordering was not actually a bug because the database already uses CASCADE deletes. There is no apparent security vulnerability here.

This commit fixes a bug in LND's SQL payment database where the code was ignoring caller-provided timestamps and always using the current time when recording when a payment succeeded or failed. The fix makes stored timestamps match the actual event time, which is important for reliable automated tests and consistent record-keeping. There is no direct security exploit here.

This change fixes a minor non-deterministic ordering bug in the database layer that returns in-flight Lightning payments. Because Go randomizes map iteration order, the list of payments could come back in a different order each time. The patch sorts the results by an internal sequence number so the order is stable. The commit message explicitly states the only current caller processes each payment independently, so existing behavior is unaffected.

This is a small internal code-quality change in LND's channel graph database. It replaces a hard-coded placeholder context with a single context variable that is passed through a few related functions. There is no security-relevant behavior change visible in the diff.

This commit is a routine code cleanup: it adds a context.Context parameter to the PruneGraphNodes function so callers can pass cancellation/timeout information. The SQL implementation previously used a placeholder TODO context, and now receives a real context from callers. There is no security-relevant behavior change visible in the diff.

This change simply threads a request-scoped cancellation context through the ChannelView database call. It does not fix an active bug by itself, but it is a small cleanup that lets long-running graph queries respect cancellation signals. There is no direct security vulnerability visible in the diff.

This commit is a routine code cleanup: it threads a request-scoped cancellation context through a graph database helper called FilterKnownChanIDs. Previously the SQL backend created a blank context.TODO() inside the function, while the caller also used context.TODO(). Now the caller's context is passed down, which is better engineering practice but does not by itself fix a security vulnerability. There is no change to access control, cryptography, network behavior, or data validation.

This change simply threads a cancellation signal (a 'context') through a database lookup function called FetchChanInfos. It does not fix a crash, stop a theft, or close a privacy hole on its own. It is a routine plumbing improvement that lets callers cancel long-running queries cleanly, which can help avoid resource exhaustion in edge cases.

This commit is a routine code cleanup: it threads a request-scoped cancellation context through the AddEdgeProof function instead of creating a blank context.TODO() inside the SQL database path. There is no security-relevant behavior change; it simply lets callers pass their own context for timeouts and cancellation.

This commit is a small internal cleanup: it threads a Go request-lifecycle 'context' through the GraphSession database-query helper so callers can cancel or time out graph lookups. The only concrete behavior change is in the SQL backend, where a hard-coded placeholder context.TODO() is replaced by the caller-supplied context. There is no direct security fix, exploit, or vulnerability visible in the diff, but it removes a future foot-gun where graph queries could not respect cancellation/timeouts.

This commit is a straightforward internal code cleanup: it threads a request context through the IsClosedScid function and all its callers. The change itself does not fix a crash, bug, or security vulnerability; it merely makes cancellation/timeouts possible for future SQL-backed calls and keeps the API consistent with other functions that already take a context.

This change simply threads a request-scoped cancellation signal (a 'context') through a database helper that records closed Lightning channels. It does not fix a crash, stop an attacker, or change any user-visible behavior. The previous code used a placeholder context inside the SQL backend, which meant database operations could not be cancelled cleanly; now the caller's context is passed through so long-running operations can be aborted if the request is cancelled. This is a code-quality and maintainability improvement, not a security patch.

This is a small internal code cleanup change in LND's channel graph database code. It adds a context.Context parameter to the DisconnectBlockAtHeight function so callers can pass cancellation/timeout information down to the SQL backend. The change does not fix a known security bug and does not introduce an obvious vulnerability. It is a routine refactoring to make the code more consistent and testable.