What the developer wrote
Authored by ziggie
docs: add payment migration release note
Document the handling of historical total-only blinded route data and the
new SendToRouteV2 validation that prevents creating such records.
What changed, and why it matters
This commit only adds a release note describing a previously fixed bug in LND's payment migration. The actual code change happened in an earlier pull request. The bug involved old payment routes that stored a 'blinded total amount' without the matching encrypted recipient data, which could cause database migration failures. The note also warns that SendToRouteV2 now rejects newly submitted routes with the same invalid combination, and that replaying an affected old route from ListPayments or TrackPayment will also be rejected. It is a documentation-only change, so it does not by itself introduce or fix a vulnerability, but it signals that a prior fix addressed a reliability issue that could disrupt node operation during upgrades.
Treat this commit as informational. Review PR #10982 and the associated code changes to confirm the migration normalization and SendToRouteV2 validation are complete and correctly handle all historical route variants. If running an LND node, ensure the release containing PR #10982 is applied before upgrading past the affected schema version.
Security signals we found
Release note references a 'payment migration failure' caused by malformed historical route data
Invalid field combination (blinded total without encrypted recipient data) is now rejected by SendToRouteV2
Potential availability/reliability impact during node upgrade/migration
No code change in this commit; signals a prior fix rather than implementing one
Evidence from the diff
The diff adds a single bullet to docs/release-notes/release-notes-0.21.2.md referencing PR #10982. The described issue: historical payment routes persisted a blinded route total amount field while lacking the encrypted recipient data (orphaned total). The migration normalizes this orphaned value, and SendToRouteV2 now validates against creating new records with the same invalid field combination. Callers replaying affected historical routes obtained from ListPayments/TrackPayment are also affected. No source code is modified in this commit; it is purely a release-note disclosure of an earlier fix.
Changed components
docs/release-notes/release-notes-0.21.2.mdLND payment routing/migration subsystem (referenced only)SendToRouteV2 RPCListPayments / TrackPayment historical route replayInspect captured patch +7 / −0
diff --git a/docs/release-notes/release-notes-0.21.2.md b/docs/release-notes/release-notes-0.21.2.md
index 4d04520..ccf4822 100644
--- a/docs/release-notes/release-notes-0.21.2.md
+++ b/docs/release-notes/release-notes-0.21.2.md
@@ -29,6 +29,13 @@
* [Fixes a bug](https://github.com/lightningnetwork/lnd/pull/10962) that
could allow the RBF closer to be used with incompatible aux channels.
+* [Fixes a payment migration failure](https://github.com/lightningnetwork/lnd/pull/10982)
+ caused by historical routes containing a blinded total amount without
+ encrypted recipient data. The migration now normalizes the orphaned total,
+ and `SendToRouteV2` rejects new routes with the same invalid field
+ combination. This also affects callers replaying an affected historical
+ route returned by `ListPayments` or `TrackPayment`.
+
# New Features
## Functional Enhancements
Why this scored 30/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.