AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 18 Bitcoin

payments/db: normalize LegacyPayload flag in migration comparison

Public commit record

What the developer wrote

Authored by ziggie

83/100 · Strong
payments/db: normalize LegacyPayload flag in migration comparison

LegacyPayload was a hint used exclusively by the KV store to decide
how to serialize and deserialize the hop payload (legacy format vs
TLV). The SQL store does not serialize hop data at all — every hop
field is persisted natively in its own column — so this flag has no
meaning there and is never stored.

Clear LegacyPayload for all hops inside normalizePaymentForCompare so
that deep-equality checks between KV and SQL payments succeed even when
the KV source data carries LegacyPayload=true.

A dedicated test (TestMigrationLegacyPayloadNormalized) is added to
verify that a payment with LegacyPayload=true hops migrates and
compares correctly.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a test-only comparison helper used when validating that old payment data can be moved from LND's older key-value database to the newer SQL database. The 'LegacyPayload' flag only mattered to the old database format and is not stored in SQL. The change makes the comparison ignore that flag so migrations with legacy-format hops don't falsely fail validation. It is not a runtime security fix and does not change how user funds or payment data are handled in production.

Recommended action

No security action required. Treat as a normal correctness/test-quality patch. If reviewing, confirm the new test passes and that normalizePaymentForCompare is only used in migration validation, not production code paths.

Security signals we found

01

No security-relevant signal: change is in migration validation/test helper only

02

No memory safety, cryptographic, or authorization changes

03

No input parsing or network-facing code modified

Risk score

Why this scored 18/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 3/15
Confidence 9/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.