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

paymentsdb: fix SettleAttempt and FailAttempt to use caller-provided timestamps

Public commit record

What the developer wrote

Authored by ziggie

83/100 · Strong
paymentsdb: fix SettleAttempt and FailAttempt to use caller-provided timestamps

The SQL backend introduced in this PR was ignoring the SettleTime and
FailTime fields provided in HTLCSettleInfo and HTLCFailInfo, instead
always recording time.Now() as the resolution timestamp. The KV backend
correctly serializes and deserializes these fields.

The timestamps are set by the caller using a mockable clock
(p.router.cfg.Clock.Now() in payment_lifecycle.go), so ignoring them
means the stored timestamp reflects when the DB write happened rather
than when the event occurred, breaking deterministic testing.

This commit also extends the test assertions in assertPaymentInfo to
verify that SettleTime and FailTime are correctly stored and retrieved
by the SQL backend, and updates the relevant call sites to pass explicit
timestamps so regressions are caught.
✓ 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 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.

Recommended action

No immediate security action required. Treat as a normal correctness/quality fix. Reviewers should verify that all call sites providing HTLCSettleInfo/HTLCFailInfo now set the timestamp fields, and that downstream logic relying on these timestamps behaves consistently.

Security signals we found

01

Data integrity / timestamp accuracy bug in database persistence layer

02

Behavioral inconsistency between SQL and KV storage backends

03

Fix enables deterministic testing by honoring mockable clock timestamps

Risk score

Why this scored 19/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 2/15
Confidence 9/10
Evidence quality 5/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.