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

sqldb/sqlc: add non-terminal payment query

Public commit record

What the developer wrote

Authored by yyforyongyu

78/100 · Adequate
sqldb/sqlc: add non-terminal payment query

FetchInFlightPayments needs a dedicated SQL query that can return
non-terminal payments without relying on the unresolved-attempt scan.
The first version of that query fixed correctness, but the follow-up
selector measurements showed a UNION-based shape was materially
faster while returning the same payment set.

Use the inflight regression tests as evidence. The tests still fail on
SQL before the Go payment store is wired up, but this commit adds the
final SQL surface the later wiring commit depends on.

Add FetchNonTerminalPayments to the SQL query set, regenerate the sqlc
bindings, add the PaymentAndIntent adapters for the new row type, and
use the UNION-based candidate selection so the final query shape lands
in one commit.
✓ 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 adds a new database query to the Lightning Network Daemon (LND) for finding payments that haven't finished yet. It is a performance and correctness improvement to how the node tracks in-flight payments. There is no indication it fixes a security vulnerability or introduces a new attack path.

Recommended action

No security action required. Treat as a normal database-layer refactor. If reviewing the broader PR, verify the follow-up wiring commit correctly uses FetchNonTerminalPayments and that the UNION query's semantics match the intended non-terminal definition across all database backends.

Security signals we found

01

No security-relevant keywords in commit title or message

02

No input is concatenated into SQL; query uses parameterized pagination ($1, $2)

03

No new external interfaces, RPCs, or permissions introduced

04

No changes to authentication, authorization, cryptography, or networking

05

Commit is framed as a performance/correctness refactor, not a security fix

Risk score

Why this scored 12/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 8/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.