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

paymentsdb: use non-terminal payment query for recovery

Public commit record

What the developer wrote

Authored by yyforyongyu

83/100 · Strong
paymentsdb: use non-terminal payment query for recovery

The new FetchNonTerminalPayments query is available, but
FetchInFlightPayments still uses the old unresolved-attempt scan until
this commit.

Use the inflight recovery regression tests as evidence. They now pass
on both KV and SQL once the payment store is wired up to use the new
query.

Fix this by switching FetchInFlightPayments to the non-terminal
payment query and batch loading only the related attempt and route
data for those payment IDs.
✓ 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 how LND's SQL payment store finds payments that are still in progress during startup recovery. Previously it scanned individual payment attempts that were still unresolved, which could miss or mishandle payments. Now it queries payments directly by their non-terminal status and loads only the related attempt data. The change is framed by the developer as fixing a regression in recovery behavior, with tests now passing on both database backends.

Recommended action

Treat as a bug-fix commit with potential reliability/security implications for payment state recovery. Review the associated regression tests and consider whether the old unresolved-attempt scan could have led to incorrect payment state on node restart. No immediate exploit mitigation is indicated, but operators should upgrade to a release containing this fix to ensure correct inflight payment recovery.

Security signals we found

01

Recovery-path logic change: affects how in-flight payments are reconstructed on restart

02

Regression-test fix: commit message says inflight recovery tests now pass on both KV and SQL backends

03

Data-consistency improvement: queries payments by status rather than by unresolved attempts, reducing risk of missing or duplicating payments during recovery

04

No explicit security advisory, CVE, or exploit details present in commit or references

Risk score

Why this scored 30/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/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.